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.

Bug 28804 - Remove NbPresenter hack with RegistryImpl.attachExplorer
Summary: Remove NbPresenter hack with RegistryImpl.attachExplorer
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Peter Zavadsky
URL:
Keywords:
Depends on: 28907
Blocks: 27868
  Show dependency tree
 
Reported: 2002-11-15 18:12 UTC by Jaroslav Tulach
Modified: 2008-12-23 10:34 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2002-11-15 18:12:10 UTC
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.
Comment 1 Peter Zavadsky 2002-11-20 15:40:25 UTC
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.
Comment 2 Peter Zavadsky 2002-11-20 16:02:43 UTC
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.
Comment 3 Peter Zavadsky 2002-11-20 17:25:25 UTC
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.
Comment 4 Peter Zavadsky 2002-11-21 09:43:50 UTC
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
Comment 5 Peter Zavadsky 2002-11-21 09:44:19 UTC
Forget to mark fixed.
Comment 6 Jesse Glick 2002-11-22 10:50:31 UTC
Fixed only in a branch, not yet really fixed.
Comment 7 Jesse Glick 2002-11-22 10:50:57 UTC
...but clearly started.
Comment 8 Peter Zavadsky 2002-12-02 13:59:21 UTC
Jesse, how do you mean it is not fixed, the hack is removed
completelly, isn't it?
Please, reopen if I missed something.
Comment 9 Jesse Glick 2002-12-02 18:54:35 UTC
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.
Comment 10 Peter Zavadsky 2002-12-10 10:09:23 UTC
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.
Comment 11 Jesse Glick 2002-12-10 17:05:06 UTC
I suppose... unfortunately Issuezilla does not support the notion of
"fixed on a branch", and I confirmed with CollabNet that Scarab will
not either. :-(
Comment 12 Marian Mirilovic 2003-01-06 13:00:06 UTC
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).
Comment 13 Jesse Glick 2003-01-09 19:47:20 UTC
I guess this is now FIXED?
Comment 14 Peter Zavadsky 2003-02-03 09:50:46 UTC
It was already merged into trunk before.
Comment 15 Jaroslav Tulach 2003-07-14 15:30:38 UTC
Definitively in trunk.
Comment 16 Jesse Glick 2003-07-14 19:31:00 UTC
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...?
Comment 17 Peter Zavadsky 2003-07-15 14:09:57 UTC
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?
Comment 18 Jesse Glick 2003-07-15 15:39:24 UTC
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.
Comment 19 Peter Zavadsky 2003-07-16 12:14:48 UTC
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.
Comment 20 Jesse Glick 2003-07-16 16:10:26 UTC
"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.
Comment 21 Peter Zavadsky 2003-07-18 10:30:24 UTC
Put the change into trunk:

core/..NbSheet.java 1.5
       NbTopManager.java 1.191
       NotifyException.java 1.50