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.
When using setQuickSearchAllowed(false) on a TreeView, there is a bug in org.openide.explorer.view.TreeView:ExplorerTree:processKeyEvent() in that it still calls qs.processKeyEvent(e) and this will consume the event, even if the quickSearchKeyAdapter has been removed. As a fix, the processKeyEvent() of the ExplorerTree should either be removed completely or at least should check if the qs is disabled, and the processKeyEvent() of org.openide.awt.QuickSearch should not forward the event to the quickSearchKeyAdapter if it is currently disabled. The effect of this is that even though the quick search is disabled (and the searchbox doesn't appear), the selected node still gets deselected after pressing a key, whereas it should stay selected. Proposed fix: org.openide.explorer.view.TreeView: @Override protected void processKeyEvent(KeyEvent e) { if (qs.isEnabled()) { qs.processKeyEvent(e); if (!e.isConsumed()) { super.processKeyEvent(e); } } } org.openide.awt.QuickSearch: @Override public void processKeyEvent(KeyEvent ke) { if (enabled) { if (searchPanel != null) { searchTextField.setCaretPosition(searchTextField.getText().length()); searchTextField.processKeyEvent(ke); } else { switch(ke.getID()) { case KeyEvent.KEY_PRESSED: quickSearchKeyAdapter.keyPressed(ke); break; case KeyEvent.KEY_RELEASED: quickSearchKeyAdapter.keyReleased(ke); break; case KeyEvent.KEY_TYPED: quickSearchKeyAdapter.keyTyped(ke); break; } } } }
Martine, I guess this one falls into your area of expertise.
Thanks for the explanation, it's fixed by changeset: 232261:97292ddfb1e1 http://hg.netbeans.org/main/rev/97292ddfb1e1
Integrated into 'main-golden', will be available in build *201209080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/97292ddfb1e1 User: mentlicher@netbeans.org Log: #216650: Do not consume key events when the quick search is disabled.
Martine, do I miss something, or it just does not work: - create Feedreader app - in FeedTopComponent.java, add line 63: view.setQuickSearchAllowed(false); - compile and run => add a few folders (nodes), try to type. QS does not appear, but selection moves as you type?!
Removing 72patch2-candidate, will be fixed just into 7.3. The performed fix is apparently not enough.
The quick search is really correctly disabled by this fix. The selection of rows as user types is performed by javax.swing.plaf.basic.BasicTreeUI$Handler.keyTyped(). Since this is an intrinsic behavior of Swing JTree L&F, I do not feel like I should suppress that. When I create a new JTree, the behavior is exactly the same.
Sorry I have not understood if this bug is going to be fixed or not. I checked out the development branch of 7.3 (235575:0e1b5c0d1ee2) and the fix in not present.
This bug was marked as fixed, which means that the fix was already applied - see http://hg.netbeans.org/main-golden/rev/97292ddfb1e1 However, the selection of rows as you type is still active, since this is an intrinsic behavior of Swing as explained in comment #6. http://hg.netbeans.org/main/file/0e1b5c0d1ee2/openide.awt/src/org/openide/awt/QuickSearch.java contains this fix, so what exactly do you think is not fixed?
I apologize for not answering, I did not get the notification. Everything is fine, my app was pointing to the wrong platform.... sorry. Angelo
Not really on topic - but is there any known workaround on a 7.2-based platform application to have QuickSearch disabled *and* not have the behaviour of jumping to nodes when pressing keys matching characters in their display names?
In my case I found a workaround but I am not sure it is going to work for you: I have some actions on the nodes of the beantreeview that have a short-cut. The main problem for me is that whenever the user selects a node and then types the action short-cut the selection jumps because of the quickSearch. In order not to loose the selection, in the body of the action (that works on the actionsGlobalContext) I select again the node for which the action was performed. It is really not elegant, the selection jumps because of the quickSearch and immediately after goes back to the original node, but is still better that loosing the selection.