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.
For recent dev builds - perhaps the last week or two? - when I open new tabs in the editor using Alt-Shift-O or Versioning > History, sometimes they are opened as the last tab as I would expect; but sometimes they are opened as the first tab instead, or if some files have already been opened in first position, after them. Ctrl-O and Ctrl-B always seem to open files as the last tab, as does Versioning > Diff. I can't find the pattern. Ubuntu, JDK 6.
i can't reproduce (on winxp) are you sure it wasn't just a case when the file had been already opened and the editor tabs just scrolled to make it visible?
Yes, these were newly opened files.
I was wrong about Ctrl-B never doing this. I had only MIMESupport.java open and pressed Ctrl-B on line 378 ("return fileObj.isReadOnly();"). Opened FileObject.java in a tab before MIMESupport.java. 071106.
Exactly the same problematic behaviour for me as well. Alt+Shift+O -> project.xml -> opened as the third tab (5 tabs opened). Product Version: NetBeans IDE 6.0 RC1 (Build 200711131200) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05 System: Linux version 2.6.23-gentoo-r1 running on i386; UTF-8; cs_CZ (nb)
Probably caused by fix of issue #101700. See issue #85666 for more details (my last comment).
Reason is there are 2 contradictory requirements: 1.Someone wants components to *remember* their position after they are closed (it applies to TC with persistence type only opened (editors) and non persistent. See issue #101700. 2.Someone wants components *NOT to remember* their position after their are closed. The things is complicated by fact that if TC instance is gc'ed, new TC is created and it is opened in last tab. If editor reuses TC it is now opened in remembered position. One solution would be: If you want editor to be opened in new position create new TC ie. do not reuse already existing TC. Question is: When reusing existing TC is correct and when not? (Similar solution could be implemented in winsys. But I have no idea what is 'correct' behavior in given moment/for given TC instance. I am afraid at this moment I cannot make happy all. Possible solution would be to extend TC persistence type to cover this. It would be API change.
*** Issue 123894 has been marked as a duplicate of this issue. ***
This is still broken. Perhaps the fix of issue #101700 can be modified to ignore TCs in the editor mode? Or to only remember that they are in the editor mode, not where?
I was thinking about adding client property to TC. Question is what should be default behavior ie. when property is not set. Probably keeping old behavior as default makes life easier (editor TC need not change anything and reporters of #101700 will add client property to their TC).
*** Issue 130434 has been marked as a duplicate of this issue. ***
Fixed in main trunk: 8390ee768f34 New client property is added to TopComponent to control behavior when non persistent TopComponent is closed. When boolean client property KeepNonPersistentTCInModelWhenClosed is set non persistent TC is kept in model when TC is closed. If property is not set (== null) then TC is removed from model ie. it is original behavior before fix of issue #101700. Added description of client property to arch document: 6beae359cbe2
I've added the property to all debugger views: http://hg.netbeans.org/main/rev/4883aaddfc67 The behavior of debugger components seems to be fine.
apichanges says: "If client property is set (!= null) then TopComponent is kept in model." In fact the code seems to behave this way as well: if (tc.getClientProperty(Constants.KEEP_NON_PERSISTENT_TC_IN_MODEL_WHEN_CLOSED) != null) {...} This is confusing. The constant is documented as a boolean property. Should rather be "If the client property is set (to true) then the TopComponent is kept in the model." if (Boolean.TRUE.equals(tc.getClientProperty(Constants.KEEP_NON_PERSISTENT_TC_IN_MODEL_WHEN_CLOSED))) {...} i.e. null should be treated the same as false.
Ok I will fix it.
Fixed in main trunk: 1f4adeaecfce.