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.
Dev build. I have a custom editor for a PropertyEditor which displays a dialog with an Explorer tree - returns a JPanel which is an ExplorerManager.Provider, includes a TreeView, etc. http://www.netbeans.org/unbranded-source/browse/~checkout~/openide/api/examples/org/netbeans/examples/modules/minicomposer/ContextPropertyEditor.java?content-type=text/plain Pressing Shift-F10 in the tree view works to display a popup, using this code: Object key = "org.openide.actions.PopupAction"; KeyStroke ks = KeyStroke.getKeyStroke("shift F10"); tree.getInputMap(JComponent.WHEN_ANCESTOR_OF_FOCUSED_COMPONENT).put(ks, key); However if you press ESCAPE to cancel the popup menu, the whole dialog closes. Expect just the popup to close. Perhaps some piece of code is not consume()ing an input event? NbPresenter.initialize() does have: getRootPane().registerKeyboardAction( buttonListener, CANCEL_COMMAND, KeyStroke.getKeyStroke(KeyEvent.VK_ESCAPE, 0), JComponent.WHEN_ANCESTOR_OF_FOCUSED_COMPONENT ); which looks very suspicious - the Javadoc for rKA says "this method is now obsolete" and explains about ActionMap's and InputMap's. If you agree NbPresenter is at fault, reassign to core, AWT/Swing. Impairs KB usage -> A11Y.
The action code is probably fine - that is, registerKeyboardAction *should* just delegate to getInputMap/getActionMap which does the same thing in a more flexible way. But we should update it to do the right thing and define an action command for it, so that if someone needs to replace the action for some reason, they can in a more reasonable way (and delegate to the original). Since the action won't know about the mouse event, it can't consume it anyway. I'd be inclined to think the problem is the menu displaying code in explorer - BUT - the action map thing is problematic anyway - if you register one action for when you're focused, and another for when you're the ancestor, both *will* get called - the only way around it I know is to override processKeyEvent and discard the event. I think that's what cured the same problem for the search field in explorer. Explorer can register an action to hide the popup on esc (probably actually the menu does this) but that doesn't stop its ancestor from processing the event to close the dialog. Probably the easiest thing is for the action to try to figure out if a popup menu is open, and if so, hide that. Or have Explorer consume the key event if it is used to close a menu. Do you really want the menu to be showable in your custom editor?
"Since the action won't know about the mouse event, it can't consume it anyway." - not sure what you're getting at (assuming you s/mouse/keyboard/): you get an ActionEvent in actionPerformed(), so you can consume it, right? Do you have any idea who is registering VK_ESCAPE on the popup menu? I can't find any usage of the constant in core, openide, or JDK 1.4.0 sources that would explain how it cancels a popup menu. Yes, I *do* want the context menus in my dialog.
I haven't the foggiest who does that for the menu - it might even be default behavior of JPopupMenu, though I don't know what it does to acheive it. It could be buried pretty deep. You can consume *your* action event caused by your action being performed. That's not the same as the action event anybody else gets, AFAIK (each action is registered with its own command, although as I recall, the event passed usually returns null from getActionCommand()).
Something that might be an option here - in NbDialog, test if the permanent focus owner = the temporary focus owner. As long as we use temporary focus on the text entry field (appropriate), and the close action will only run if the permanent and temporary focus owners match, we may have a generalized solution for this type of problem. Interestingly, though, when a menu is up, the focus is the JRootPane. Go figure.
FYI, I now do know who does the Escape behavior - it's in NbPresenter. Possible fix there would be something like: if (KFM...getPermanentFocusOwner() !+ KFM...getFocusOwner()) { //return, don't process the action } Might cause problems elsewhere, I don't know. But since menus receive temporary focus, this should be a reliable way to detect if a menu (or other popup which should process the escape) is open.
i can't reproduce this behavior anymore