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.
After deleting a Java source file from the project window, the cursor position is completely lost. It would be good if the cursor position is on the member above or below the deleted member, on the same level, or if the deleted file was the last in the package, then the new cursor position is on the package node. This is best reproduced by using only the keyboard not the mouse. The fix would improve the handling substantially - I hope it is not too dificult to do.
Yes, it really is - but it shall not be this way, the file next to the one deleted shall remain selected.
My ergonomics#83a72132b938 fix is not ideal, but it will at least select a parent in these situations.
Integrated into 'main-golden', will be available in build *201103040000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/83a72132b938 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #193852: Select parent when last child is removed
In RC1, in the project window, the cursor goes to the top, to the first project.
Created attachment 119828 [details] Sample project The selection in sample BeanTreeView with Children.Array behaves as expected (selects a sibling after delete), so the misbehaviour in favorites window must be cause by deeper problems.
Created attachment 121087 [details] Improves the behaviour, but I struggle writing test to ensure it
Let's see if the following change helps: ergonomics#690b16f169be
Integrated into 'main-golden', will be available in build *201211070001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/690b16f169be User: Jaroslav Tulach <jtulach@netbeans.org> Log: #193852: Attempt to improve behavior of selection after BTW delete. Give it some testing please.
When I delete files, in the project window, then then the IDE locates at the top of the tree, at the first project.
Passing to default explorer owner.
ergonomics#690b16f169be made it even worse, i can reproduce in almost 100% cases. it seems simply deleting file results in events coming in different order (NodeDestroyed, NodeRemoved) instead of (NodeRemoved, NodeDestroyed). bht: does it help if you delete a file not using Delete action (Delete key) but via Refactor -> Safely Delete (Alt+Del) ?
> bht: does it help if you delete a file not using Delete action (Delete key) but via Refactor -> Safely Delete (Alt+Del) ? Besides that, what project type are you using?
I use a Maven project. Safely Delete (Alt+Del) works fine in case there is a dialog I must confirm. I haven't checked the case where (Alt+Del) does not pop up a dialog.
Created attachment 143159 [details] possible patch draft
A bit of evaluation: it happens because DataSystems fire DataNode.fireNodeDestroyed() before it is removed from the node hierarchy via setKeys() method. ExplorerManager reacts on nodeDestroyed and if the destroyed node was a selected one it is deselected. Then the trick in TreeView cannot take place because there is no more any selection. Potential fixes might be: A) data systems do it in the right order - probably out of the question, who knows what regressions it could cause. B) seems node.destroy() tries to remove nodes from hierarchy itself but Children.remove(node) is a noop in this case because children for file trees is lazy and simply skips the removal - is there a space for improvement??? C) explorer manager may be smarter and either move the selection to the parent (attached patch may do the trick but i am no Node/Explorer expert and i cannot see far enough to know all negative consequences). Or maybe it could be reviewed and the code removing the selection may be completely skipped? What is the motivation if the node is still visible in UI and can be selected by user again anyway?
Created attachment 143253 [details] fix and tests
jardo, honzo, can you please take a look at my patch proposal? Contains a potential fix and unit tests. The fix is in ExplorerManager: the manager listens on nodeDestroyed and removes the selection only when the node is no more in parent's children. Does it make sense this way?
Seems OK. Possibly one may not listen to destroyed event at all - enough to verify the Node is still in the hierarchy.
> Possibly one may not listen to destroyed event at all - enough to verify the Node is still in the hierarchy. Well, if i stop removing the selection in nodeDestroyed completely then ExplorerManager.testSetNodesSurviveChangeOfNodes starts failing.
fix: http://hg.netbeans.org/core-main/rev/54135b2ac379