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.
Summary: | ESCAPE pressed to cancel popup in tree view in proped dialog closes dialog | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Explorer | Assignee: | Stanislav Aubrecht <saubrecht> |
Status: | RESOLVED WORKSFORME | ||
Severity: | blocker | Keywords: | A11Y |
Priority: | P4 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jesse Glick
2003-09-26 23:13:27 UTC
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 |