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.
TreeViewDragSupport resets the selected nodes after drop (line 90). That is needless for cases when the drop is performed to other than the original component, and also it break rare (but possible) case when there are set other selected nodes during DnD (our case). I tried to fix it using 1) the DragSourceDropEvent.getLocation which was supposed to return screen coordinates point, but did return (linux) the point whitin target component coordinates, while it doesn't offer the target component, and thus the point wasn't possible to convert and find out whether the drop occured whitin original component or not. 2) other approach could be to reset the nodes only in case they were not set to other value by client code already. 3) to avoid the reseting completelly (it should be needed only when DnD whitin same component and that could be managed from other methods).
I tried dragging a file from projects explorer to favorites explorer, and after drop, both explorers kept their previous selection, so I see no problem here. If you still see some problem, please precisely describe actions, the outcome you see and the outcome you expect.
You probably cannot reproduce it in NB. You should create this scenario (test case). 1) Start drag nodes N1 from explorer 2) During the dragging operation, programatically setSelectedNodes of that explorer to N2 3) Drop the dragged nodes N1 (to some other component than the original explorer) 4) After the drop the selected nodes of the explorer are not N2, but they switch back to N1. That is the scenario we are hitting, the programatic set of the selected nodes is cleared by the code machinery described in the first comment.
Sorry, but I have to revoke this. IMHO your scenario is wrong from usability point of view anyway.
I don't understand why it is wrong, could you explain it? This is not about usability but about the API.The current implementation doesn't work under described cirumstancess. I don't see a reason why it shouldn't. There is no such contract mentioned in the documentation that it is not supposed to work.
IMHO there are two ways to fix this: 1) (my preferred) Add javadoc note to setSelectedNodes, saying that if called during user action that modifies selection like DnD, results are undefined. Changing selection programmatically during user's DnD is serious UI error, I can't imagine situation in which it would be proper behaviour. User won't have a chance to understand what is going on and will always report that "selection is not remembered". So IMHO our API shouldn't support such cases with broken UI. 2) Accept any setSelectedNodes call and force its setting. However even in such case, I would put javadoc warning in, as I see it clearly wrong from UI perspective. pzavadsky, may I know some details about your use case that leads to calling setSelectedNodes during DnD? Thanks.
To the usage scenario: Here is it used in this scenario: 1) Dragged nodes from explorer 2) Dropped to some other component, 3) based on that drop action the nodes in the explorer are set to null (calling the API - because of one strange contract in our impl) 4) but the nodes are immediatelly reset to the original by NB impl (the code I pointed out) The above scenario might not be nice (actually I fought against such implementation), but I also admit that it is legal (the setSelectedNodes call). To the fix: I think the fix shouldn't be that complicated. Let's look at the code (TreeViewDragSupport). I think, the purpose of the original impl (the reseting of the nodes), makes a sense only when you are moving (by DnD) the nodes whitin the same explorer, i.e. when you change their location whitin the tree. In all other cases you shouldn't set the selected nodes to the dragged ones. I.e. in our scenario, when the drop was performed to the other component than the the original explorer there shouldn't happen any reset to the dragged nodes. So this issue would be easy to fix, if you just check whether the drop component is the same like the original explorer. On the other hand, to make the fix complete (to work for all scenarios), i.e. to respect any setSelectedNodes call, you'd need to compare the dragged nodes to the selected ones, and reset only in the case they are the same (or subset of the selected?!). Well, it is up to you. I just thought the fix would be relativelly easy supposing the above assumptions are correct, and it would make the ExplorerManager more robust, without need to provide such info into javadoc, which would sound a bit strange.
Reassigning to new module owner Tomas Holy.
This bug was reported against NetBeans IDE 6.0 or an older release, or against a non-maintained module. NetBeans team does not have enough resources to get to this issue, therefore we are closing the issue as a WONTFIX. If you are interested in providing a patch for this bug, please see our NetFIX guidelines for how to proceed. We apologize for any inconvenience. Thank you. The NetBeans Team