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 38475

Summary: PopupMenu does not work following examples in ExplorerUtils
Product: platform Reporter: Petr Hrebejk <phrebejk>
Component: ExplorerAssignee: Jaroslav Tulach <jtulach>
Severity: blocker CC: apireviews, jglick, jtulach
Priority: P3 Keywords: API_REVIEW_FAST
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: Addition of TopComponent.associateLookup

Description Petr Hrebejk 2004-01-07 10:47:04 UTC
When creating Explorer using BeanTreeView:

Rather annoying. I tried with the
ActionMapPopupAction =
a);but this just caused a StackOverflowError when
I tried to press S-F10!

Anyway it is not supposed to be necessary to do
anything, since the BeanTreeView already has PA's
key in its ActionMap

It works with Jardas workaround:
Comment 1 Jesse Glick 2004-01-07 16:01:11 UTC
Note that such a trick is not necessary for e.g.
PhadhailViews.ExpPanel in threaddemo - S-F10 works automatically.

Shouldn't TopComponent's processKeyBinding override take care of this
Comment 2 Jaroslav Tulach 2004-01-08 15:03:58 UTC
What exactly makes it work in PhadhailViews.ExpPanel? Who is handling
the Shift-F10 shortcut?

I have identified the problem with that the ActionMap
in globalActionContext is not,
but just the actual getActionMap returned from TopComponent. The
solution might be to always return DelegateActionMap from
Comment 3 Jesse Glick 2004-01-08 15:55:25 UTC
In PhadhailViews, there is only

Object key = "org.openide.actions.PopupAction";
KeyStroke ks = KeyStroke.getKeyStroke("shift F10");

where tree is a BeanTreeView. Otherwise there is no binding for S-F10,
of course.

In the case of ProjectTab, S-F10 is not bound in the input map as
such, but the window system's ShortcutAndMenuKeyEventProcessor
interprets it anyway. However for whatever reason, in this case the
ActionMap for the BeanTreeView is not searched.

I don't really understand why that is, but I presume whatever the
reason, it is the justification for DelegateActionMap. Which would
mean that ProjectTab does in fact need to return a delegating
ActionMap from its Lookup.
Comment 4 Jaroslav Tulach 2004-01-11 15:30:20 UTC
Created attachment 12820 [details]
Addition of TopComponent.associateLookup
Comment 5 Jaroslav Tulach 2004-01-11 15:33:25 UTC
Seems that the only way how to fix this problem is to allow to
associate lookup to TopComponent after the super constructor is
finished and also by default use DelegatingActionMap as the map for
all top components. I've added protected final
TopComponent.associateLookup method that can be called once. Is this
acceptable solution? Is this the right name for the method? Can it be
final, or should I make it non-final?
Comment 6 Jaroslav Tulach 2004-01-19 08:41:47 UTC
Thanks for review, will be implemented tomorrow.
Comment 7 Jaroslav Tulach 2004-01-20 10:11:42 UTC
Checking in;
/cvs/openide/,v  <--
new revision: 1.131; previous revision: 1.130
Processing log script arguments...
More commits to come...
Checking in api/doc/changes/apichanges.xml;
/cvs/openide/api/doc/changes/apichanges.xml,v  <--  apichanges.xml
new revision: 1.184; previous revision: 1.183
Processing log script arguments...
More commits to come...
Checking in src/org/openide/explorer/;
/cvs/openide/src/org/openide/explorer/,v  <--
new revision: 1.4; previous revision: 1.3
Processing log script arguments...
More commits to come...
Checking in src/org/openide/windows/;
/cvs/openide/src/org/openide/windows/,v  <--
new revision: 1.5; previous revision: 1.4
Checking in src/org/openide/windows/;
/cvs/openide/src/org/openide/windows/,v  <--
new revision: 1.116; previous revision: 1.115
Processing log script arguments...
More commits to come...
RCS file:
Checking in
initial revision: 1.1
Checking in
new revision: 1.18; previous revision: 1.17
Comment 8 Petr Hrebejk 2004-01-20 10:39:08 UTC
I've tested the fix and it works for me => Verified.