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.
Replace the ugly and not well working hack with attachExplorer by the new Action framework. If the component implements ExplorerManager.Provider, implement Lookup.Provider by NbPresenter and do not call the attachExplorer at all. This will guarantee that NodeAction and Callbackctions will work.
Implementing Lookup.Provider in NbPresenter doesn't work, since it is "hidden" by the TopComponent lookup (in our case the explorer panel) which is lower in AWT hierarchy. (The lookup provider is searched from bottom to top of AWT hierarchy and taken the first one). Some "more sophisticated" policy or trick is necessary to figure out. Thinking about it.
Hm, I now wonder why the Lookup provided by that explorer panel (in the dialog) isn't enough. It should be enough and work fine as I understood the concept. But doesn't, going to look at it why.
Problem is when the ExplorerPanel is used just as ordinary Component (not TopComponent) like it is in the customizer (invoke from Filesystems | Customize...). In that case the ExplorerPanel doesn't update its activated nodes according to the actual selection -> there is not started listening on its explorer manager -> not called open method.
Fixed in [action_27868] branch. org/openide/explorer/ExplorerPanel.java 1.32.84.3 org/netbeans/core/windows/RegistryImpl.java 1.30.12.1 org/netbeans/core/windows/WindowManagerImpl.java 1.157.4.1 org/netbeans/core/NbPresenter.java 1.71.6.1 org/netbeans/core/NbTopManager.java 1.169.2.1 Note: For a while the scripting module is not compilable -> issue #28907
Forget to mark fixed.
Fixed only in a branch, not yet really fixed.
...but clearly started.
Jesse, how do you mean it is not fixed, the hack is removed completelly, isn't it? Please, reopen if I missed something.
It is not fixed in the trunk. You fixed it in a branch which you have not merged. If and when you merge it, mark this fixed, not before.
I supposed I mark this as fixed even it is only in the branch, and after merge I just mark the top issue #27868 as fixed.
I suppose... unfortunately Issuezilla does not support the notion of "fixed on a branch", and I confirmed with CollabNet that Scarab will not either. :-(
Peter, don't forget close this issue and set appropriate target milestone. I have changed version from 4.0 dev to S1S 4.2 (Nevada).
I guess this is now FIXED?
It was already merged into trunk before.
Definitively in trunk.
Seems to be fixed, though I am curious why NbSheet needs the following code still: public void propertyChange(PropertyChangeEvent ev) { if (ev.getPropertyName().equals(TopComponent.Registry.PROP_ACTIVATED_NODES)) { if(!NbTopManager.isModalDialogPresent() && NbSheet.this.isShowing()) { activate(); } } } If there is a modal dialog showing, why would TC.R.P_A_N be fired at all...?
I didn't change the semantics (just replaced the code)... I digged in a bit.. and it seems it was originaly added in revision 1.78.2.1 of NbNodeOperation... which refers to issue #18245. Well, now I'm not sure... but I guess even modal dialog could contain some nodes and activate them, doesn't it? Or was there changed anything?
I'm not positive, but I think issue #18245 was entirely a result of the RegistryImpl.attachExplorer hack - when you opened a modal dialog with a tree view etc. in it, you had to fire TC.R.P_A_N in order to ensure that any NodeAction's present in the dialog actually worked. But now this hack is unnecessary and removed, so opening a modal dialog should never be changing the global activated nodes, so there is no need at all for NbSheet (or any similar code) to care about dialogs being opened or closed. At least as far as I understand it.
Aha, now I understand, it seems you are right. So when removed that from NbSheet, then will remain only usage of that method in NotifyException source, thus it could be moved there from NbTopManager.
"So when removed that from NbSheet, then will remain only usage of that method in NotifyException source, thus it could be moved there from NbTopManager." - yes, probably so.
Put the change into trunk: core/..NbSheet.java 1.5 NbTopManager.java 1.191 NotifyException.java 1.50