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.
Caret is sometimes set at wrong position during source opening. How to reproduce: 1. make sure that the opening file is not already open in the editor 2. expand class node in the explorer to the members level, i.e. ColorPicker/class ColorPicker/Fields/... 3. double click on the field. The source should be open in the editor and the caret should be at the position of the selected field. Unfortunatelly, sometimes it not. It seems that it is race condition problem, the setDot method is sometimes called in wrong order: First: offset:1876 java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1071) at org.netbeans.editor.BaseCaret.setDot(BaseCaret.java:783) at org.netbeans.editor.BaseCaret.setDot(BaseCaret.java:773) at org.openide.text.CloneableEditorSupport$1$Selector.run(CloneableEditorSupport.java:1436) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:448) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) Second: offset:0 java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1071) at org.netbeans.editor.BaseCaret.setDot(BaseCaret.java:783) at org.netbeans.editor.BaseCaret.setDot(BaseCaret.java:773) at org.openide.text.CloneableEditor$2.taskFinished(CloneableEditor.java:208) at org.openide.util.Task.notifyFinished(Task.java:121) at org.openide.util.Task.run(Task.java:138) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:328) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:668) It causes, that the caret is wrongly set at the begining of the document.
Mato, thanx for the precise problem description. It helped a lot. Fixed in file: Checking in src/org/openide/text/CloneableEditor.java new revision: 1.58; previous revision: 1.57 QA people: I would consider this as candidate for NB35. It is probably not reproducible. The fix is trivial and it seems to me that it should happen quite often. Opinion? Petr Zavadsky: Peter, could you please review the change. It is simple. Look at the Mato's StackTraces and compare them with my fix - it should be obvious. It seems to me that it could teoretically happen quite often.
Yes, I agree, the patch seems to be simple & robust.
If so, I would also vote for integration to release35. It can be reproduced in many cases, not just opening the specific member from explorer. Also simple class opening should set the cursor position to the class declaration. Another cases: Alt+O, Alt+G, Alt+Shift+O ...
Increasing priority to get this into NB35. The bug can be highly visible and irritating. The fix is trivial and was reviewed.
Integrated to NB35: Checking in src/org/openide/text/CloneableEditor.java new revision: 1.57.2.1; previous revision: 1.57
Mato, could you please test it? I was not able to reproduce it on my comp.
Works OK in the build 20030307-1441 Thanks.
Although one minor issue still remained: If you try to open java source file, that has no form (i.e.:examples/colorpicker/ColorPreview), the caret is not placed at the class declaration, but in the offset 0. After your fix (build 20030307-1441)no setDot is called, before the fix (build 6.3.) only setDot(0) was called.
And who is opening the file? Does he set any line offset? Sounds to me like plain opnening of java file without any line specified.
Yes, you are right. It is as designed behavior. I was too biased on Alt+O opening, where the cursor is placed on the class declaration position...