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.
[dev jun 22] If a node is selected in the Explorer and then deleted (either by user action, or just things refresh and it no longer exists, etc.), the Explorer should make an attempt to select some nearby node. Otherwise the user is left with no selected node and must start finding his place from the top of the Explorer. If there are many nodes visible in a deep nesting structure, this can take a significant amount of time.
*** Issue 15875 has been marked as a duplicate of this issue. ***
Target milestone -> 3.3.1.
*** Issue 18924 has been marked as a duplicate of this issue. ***
Seems reasonable to me (and doable for 3.4). Only complicated part is definition of "nearby" node: Could it be some node with the same parent and index n+1 or n-1 or parent node in case folder will be empty? (or give up otherwise) I expect problems with multiple node deletion, selection is best to perform *after* all deleting is done.
Could be parent node. I would say: given the current expanded/contracted state of nodes, "nearby" means adjacent (up or down) if you were to sort all nodes according to vertical position in Explorer, regardless of nesting level. I.e. where you would go if you were to press Up or Down arrow rather than Delete.
Set target milestone to TBD
Created attachment 7921 [details] selects nearby node when node is deleted
Here's something to select a nearby node when a node is deleted. I've only done minimal testing, but it seems to work for me. It tries to select the sibling above (I followed MS NT File Explorer) or parent if required. This should definately be reviewed, I'm not comfortable making changes here (and as I look at the diff, I can see a few changes I'd make). :) Next would be the treetable...
John, great! I didn't try it, but I'm looking forward to see this functionality in dev builds soon...
Ah, I'm a bit worried about two things: if the node will always be a TreeNode (if the cast will always work) and if this is always done on the AWT thread. When I get a chance I'll check these.
It looks like I didn't have to worry about those things... TreeNode is commonly used, and it looks like all invocations are on the AWT thread. (I only verified this with a println though, not analysis). Otherwise, it now works for the TreeTable (breakpoints, watches). Again, minimal testing, but it works for me.
Created attachment 7944 [details] patch for both treetable and trees
One more thing... the code is basically a copy/paste job and the body of treeNodesRemoved should probably be impelemented someplace common. But there doesn't seem to be such a place at the moment. Ideas: a JTree.TreeModelHandler subclass which is subclassed by TreeView and used directly by TreeTable, or a static function which is common to the two.
John, thank you for your patch above all. I'm now time pressed by other tasks. I'm going to look on in and integrate asap. Keep patching the code furthermore it's very valuable and great.
The patch was applied and committed to main trunk. I added the method findSiblingTreePath which is called from TreeView and from TreeTable too, in TreeView was called requestFocus to have focus on the newly selected node. Thank you for this patch it's very handy.
Created attachment 8103 [details] fix for breakpoint problem
I reopened this because there seems to be a bug when removing breakpoints. I noticed this in todays 4.0 dev build (dev-200211280100). Unfortunately, I don't have CVS set up for the dev builds, but this change is pretty much self contained within TreeView.java, so I attached the findSiblingTreePath function... hopefully someone can put this into the dev builds...
I should mention that that problem was, if you add two breakpoints in the editor window (with shift f8) and then hit shift f8 a few times to add/remove/add a breakpoint in the editor window, there was an index out of bounds where no children were affected by a delete (but delete was called).
Setting this back to fixed... jrechtacek applied a fix and apparently a seperate bug was opened (which I missed).
verified in [nb_dev](20021211)