This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Surprisingly frustrating: Type into the editor in some java file. Press Ctrl-S. Beep. Press Ctrl-S again. Beep. Press Ctrl-S again. Beep. Press Ctrl-S again. Beep. Press Ctrl-S again. (Pounding keys in frustration) Beep. Press Ctrl-S again. (Hammering keys in frustration) Saved. Apparently typing anything in the editor starts some kind of delay during which the file cannot be saved. If you compulsively press Control-S every time you make some small change to a file, this is really, really irritating - even though I know what it's going to do. Surely there's some way to notice if the user attempted to save in the time the delay was active, and do the save after a timeout, if really necessary. What's going on here?
Yes, I hit this too. The difference is that there is no beep for me on windows, so I just have to look for the modified sign if it finally disapeared. I usually manage to save the file on second Ctrl+S.
ditto, even in beta 2 (JDK 5, WinXP). Files will usually be save on the 2nd ctrl-S but it is annoying. The IDE has to be at least as fast as I am - and I'm a slow typist!
I am not able to reproduce this in the current build. Can you? We have fixed a bug that may have caused blocking of getCookie calls on JavaDataObject. This could be the cause of the problem. So I am closing this as works for me, please reopen if it happens to you in the current build and let us know if it happens consistently are whether there are reliable steps to reproduce it.
Might be better now, but I'm still able to reproduce it on 20041007 custom build. One Ctrl+S is simply forgotten. It seems to be related to background parsing - that if I hit Ctrl+S when the parsing starts or finishes (don't know) the file is not saved.
When I was trying to reproduce it, I edited a code and immediately hit Ctrl+S and it always worked. Since you say it may be related to a background parsing, does that mean that it *does* work for you immediatelly after typing, but stops working in a short while after you finish typing (when the 2 seconds limit for background parsing is reached) and then starts to work again later?
It also happens for me even with build 200410052201. I have a habbit of pressing Ctrl+S even after a small change. Quite often, when a change is immediately followed by Ctrl+S, the file isn't saved (the * after the file name remains). It has something to do with a background task, because it usually happen when my CPU is busy or after switching to an other applications and Windows swaped out a part of netBeans process.
To Martin: I will probably disapoint you but the case you describe is just better reproducible but I still can reproduce the scenario that you were unable to reproduce. It can be usually reproduced if I change type of edits done in editor. If I just type, hit Ctrl+S, type, hit Ctrl+S, type, hit Ctrl+S it usually works but If I delete block of text and then write something and then Ctrl+S sometimes even fourth Ctrl+S do not work as expected.
You did not disappoint me :) - it is the opposite. I am happy that you've provided more info that will help us to identify the problem...
I'll look at it.
I simply don't know what's happening here. It looks like SaveCookie is correctly attached to DataObject right after modification, but SaveAction is still disabled. I'm not sure, but this bug can be somehow connected to issue 44501.
*** Issue 50225 has been marked as a duplicate of this issue. ***
Openide guys, please help. It looks like SaveCookie is correctly attached right after modification, but SaveAction is still disabled. I don't understand implementation of CookieAction, but I tried to add some debug messages to CookieAction, and I realized, that SaveAction(CookieAction).resoveSupported() sometimes returns 0 even if result getCookies() contains SaveCookie. Is this correct? Please evaluate, thanks.
Increasing priority to P2 because it is highly visible and annoying behavior.
As one part of the evaluation we shall ask whether such behaviour ever happened somewhere else than in java source. According to my knowledge, it has not. Then one should ask what is so different on java source than on other source editors. The first thing that comes to my mind is EditorSupport. Nearly every one already migrated to CloneableEditorSupport, java is the last one (known to me) that is still using EditorSupport. Maybe this is the problem? Well, if it is there is simple solution, rewrite JavaEditor to use CES. However I am skeptical about this possibility, as the code in EditorSupport seems to do good work and I was not able to find a mistake there. The other different thing that java editor does is its top component. It does not use CloneanbleEditor directly (or EditorSupport$Editor which just extends it), but has some subclass that mangles with activated nodes. This looks like a more probably source of the problem, as the selected node is completely under java module control and thus it is possible that it is broken. This might be signaled by the fact that after two seconds of inactivity the save action is enabled. How can this happen? Well, somebody had to fire a cookie change or change in the lookup. What task takes two seconds from save to finish? Is not that java parsing? Can it generate some cookie change? Maybe. Could it happen that such change rechecks the action state and finds out that there is already a SaveCookie from previous acient times? Yes, it could. That is why I believe the bug is in java, passing back to the java module. Please verify that your mangling with nodes is not cause of the problem - e.g. find out what is the node that save action checks and finds out that it has no SaveCookie.
> Maybe this is the problem? Well, if it is there is simple solution, rewrite JavaEditor to use CES. Yes, but we are not going to rewrite it few days before high resistance. > The other different thing that java editor does is its top component. It does not use CloneanbleEditor directly (or EditorSupport$Editor which just extends it), but has some subclass that mangles with activated nodes. Honzo P. Jarda wrote, that possible cause of this bug could be in setting of activated node. Can you take a look at it, please? Thanks
I have encountered this kind bug too, where Ctrl-S does nothing the first few times you press it, but also on XML files.
Yarda, from Jesse's comment it seems that this problem is more general (not strictly related to JavaEditor). People probably noticed it with Java files since it is not 100% reproducible and Java is what they are editing most of the time, so there is a higher probability they run into this.
I played with it yesterday. I was able to reproduce it quite simply. The SaveCookie is asked form the active node that is usually subnode of JavaNode. The element node delegates to org.openide.src.Element and it delegates to JavaDataObject. So if EditorSupport notifies the JDO properly the cookie is available also on the active node. I do not think the delay relates to the parsing since CloneableEditorSupport registers its document listener that adds SC to JDO immediately. Unfortunately, if I add a debug info everything begin to work well.
I have found a solution at least for java files. ElementNodes that are selected as active nodes listens to the data object now in order to propagate the save cookie to its lookup. So they no more rely on the org.openide.src.Element's node lookup. It also solve enum and annotation type nodes which cannot delegate to org.openide.src.Element. Fixed in /cvs/java/src/org/netbeans/modules/java/ui/nodes/elements/ElementNode.java new revision: 1.14; previous revision: 1.13 /cvs/java/src/org/netbeans/modules/java/ui/nodes/JavaSourceNodeFactory.java new revision: 1.17; previous revision: 1.16
*** Issue 50814 has been marked as a duplicate of this issue. ***
*** Issue 51058 has been marked as a duplicate of this issue. ***
Verified in 4.2 (200507110943)