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 jan 15] Open a org.netbeans.core.FileSelector somehow (i.e. call org.openide.nodes.NodeOperation.select on some root node). As you are moving through the resulting dialog, you can use the new type-to-search feature to quickly navigate. But you cannot cancel the search field easily: if you press Esc, rather than just closing the search field, the whole dialog is closed. TreeView.ExplorerTree.SearchFieldListener.keyPressed catches VK_ESCAPE and calls removeSearchField(). It does not call e.consume(), but adding this call does not seem to help. The code to close a FileSelector when Esc is pressed is in that class's constructor.
Causes problems for KB navigation of this dialog.
Jesse, could you give me a set of steps to reproduce this in the running IDE? I haven't digested all our myriad UI components yet, so I don't know offhand what operation will create a FileSelector. Sounds like it should be easy to fix, at worst override processKeyEvent, if it's VK_ESCAPE, see if the nav component is open, and if so, never call super.processKeyEvent() for that key.
The search field actually uses a KeyListener. I am not well enough versed in the ways of Swing KB handling to understand why it does this, rather than register a KB action, which is a completely different API call. Maybe it is just a mistake. As to opening a FileSelector: it is not too commonly used. Try navigating to a bean class in Explorer and choose Customize Bean, then Serialize As. Or for a more controlled test, run w/ internal execution: import org.openide.nodes.*; public class RunFS { public static void main(String[] args) throws Exception { Children c = new Children.Array(); c.add(new Node[] { new N("alphabet"), new N("breakfast"), new N("cookie"), new N("dialectical materialism"), }); Node n = new AbstractNode(c); n.setName("master"); NodeOperation.getDefault().select("title", "root title", n); } private static final class N extends AbstractNode { public N(String n) { super(Children.LEAF); setName(n); } } } Press D, then ESCAPE. Expected: search dialog closes, selection left on "dialectical materialism". ESCAPE again closes whole dialog, UserCancelException printed on console. Actual: whole dialog closes w/ first ESCAPE.
I had a similar problem with property sheet - it has a pile of action commands and keeps listening to keys when a custom editor is open (so, for example, in a combobox, the down arrow should select the next item, and it does, but the JTable also is listening and thinks it should change the selected property, so the editor gets closed). For propertysheet I implemented a heavier weight solution, which involves a custom InputMap that delegates to the default one, so that an inplace editor can supply a set of keystrokes that shouldn't get propagated while it's open. The entry point is the default implementation of processKeyEvent - if you're only concerned about a single keystroke, the simplest way is to simply override it and conditionally call super.processKeyEvent(). If you want to get fancy, you could yank the keystroke out of the input map while the nav field is open, but that's probably overkill.
Isn't the default KB manager supposed to just look in components starting w/ focus owner outwards for one whose input map registers that keystroke? That sounds like the simplest thing to me. Or is this only applicable to some situations?
Fixed in trunk, TreeView 1.127
verified in [nb35](20030317)