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 200311301900 In the REPLACE dialog, there is no shortcut key for FIND, instead it is assumed ENTER will trigger the default action, which in this case is FIND. The problem is that once an entry has been replaced, REPLACE becomes the default action associated with ENTER and there is absolutely no keyboard shortcut for FIND. You could use arrow keys and such but the UI does not act as expected. Expected behavior: either add a shortcut key for FIND or make sure ENTER *always* triggers find regardless of where the cursor is.
we should fix it to NB 3.6
Fixed in [maintrunk]. /cvs/editor/libsrc/org/netbeans/editor/ext/ExtKit.java,v <-- ExtKit.java new revision: 1.39; previous revision: 1.38 done /cvs/editor/libsrc/org/netbeans/editor/ext/FindDialogSupport.java,v <-- FindDialogSupport.java new revision: 1.36; previous revision: 1.35 done
Reopening issue. I can reproduce it under build 200403111900.
I can't reproduce it in NetBeans 3.6 RC1 200403151830. My steps : - opened F&R dialog - typed some text in textfields in this dialog - used Alt-R -> this replaced text - used Enter -> this found next occurence of finding text Am I doing something wrong ?
Petr, I have the exact same repro steps as you so something else is going wrong. Here is what I just did: 1) Download dev build 200403151900 2) Extract build into new directory (free userdir) 3) Run under JDK 1.5 beta 1 (maybe this is it?) 4) Open text file 5) hit CTRL-H 6) Typed some text 7) hit ENTER a few times (did not replace the first couple instances) 8) Hit ALT-R to replace 9) Hit ENTER to "find" but "replace" took place instead My initial guess is that this is JDK 1.5 specific. What JDK are you using?
Changing subcomponent to "search"
Sorry for my first comment. I tried to reproduce it, and it is reproducible. I used in test jdk1.4.2 and 1.5.0 on Win XP.
I will look at this as I am using winXP and I can reproduce it. I have found it is connected with L&F... (I cannot reproduce it using metal L&F on winXP)
It seems it is openide (or JDK) problem... DialogDescriptor. The same problem with default button in editor's search&replace dialog appears also in ExitDialog(org.netbeans.core). ExitDialog also uses DialogDescriptor, (with default button - Save). How to reproduce: 1. Use winXP L&F, the problem is unreproducible on i.e. metal L&F 2. modify some source and try to close IDE 3. Save dialog appears with default button correctly marked on saved button (blue rim) 4. press tab to transfer focus on Discard All (you can notice, the default button mark is moving along with the focus) 5. if Discard All button is selected and you press Enter, the default button operation should be invoked - it means save, but instead Discard is invoked. Reassigning to core for further investigation.
Martin, UI team, I would like to point out how utterly unintuitive this "default button" thing sounds. Think about it, "Discard All" is selected and the user hits "Enter" and he gets "Save" instead just because you and I know it happens to be the default setting? Sounds very un-keyboard-user-friendly and very unintuitive from a UI point of view as well. The user is expecting the selected button to get invoked when ENTER or SPACE or whatever other action button is pressed. Default buttons should simply be the button that is selected by default when you first bring the dialog up, and it should have its own shortcut key in case you moved off it. Just my 2 cents...
Gili, > Think about it, "Discard All" is selected and > the user hits "Enter" and he gets "Save" instead > just because you and I know it happens to be the default setting? Default button is highlighted, so it is obvious that hitting enter invokes the action of highlighted default button. > The user is expecting the selected button to get invoked when > ENTER or SPACE ENTER is binded to default button by default, such as ESC to Cancel. User should use SPACE to invoke selected button > Default buttons should simply be the button that is > selected by default when you first bring the dialog up, > and it should have its own shortcut key > in case you moved off it. Just my 2 cents... In accordance with L&F guidelines: "Two common exceptions are the default button (activated by hitting Enter or Return) and the Cancel button (activated by hitting Escape) - these should not have an associated mnemonic." I think the main problem is that the highlighting of the default button is broken after focus lost during tab navigation as I wrote in my previous comment. Note, it seems this is a defect of Dialog Descriptor, the issue is unreproducible on wizards dialogs, or i.e. autoupdate dialog...
Martin, I wasn't aware that the default button is meant to remain highlighted at all times and this was the actual bug being reported. I agree with you now. Thanks for the clarification.
No, it's not bug in DialogDescriptor. Behavior of the default button is different on Window XP L&F, the being focused button takes precedence when an user invokes Enter. I propose: don't change focus when Ctrl-R is invoked and add new shortcut to Find. Btw: it works for me on Metal L&F.
OK, if it is standard WinXP L&F behaviour, resolving the issue as WONTFIX. We will not provide any workaround against standard :-)
Martin, As Jiri pointed out, this is a L&F issue. You shouldn't just close it as WONTFIX because the behavior under the Windows L&F is still unacceptance and does not match the behavior of native Windows applications. Native Windows applications have a shortcut key for the "default action" (in this case "Find" or "Replace"). As such, if you decide to honor the Windows L&F, you must add shortcut keys for Find or Replace when Windows L&F is in use. The current behavior exibits usability problems.
Gili, OK, adding mnemonics for Find and Replace should help, but it seems it is common IDE dialog problem. For example try the dialog Refactor/Rename... You will see two enabled buttons at the bottom - Cancel and Help. Using TAB key, you can notice that default button is moving within the focused button (the blue rim is cycling) OTOH, try Run/Attach Debugger/ - there are OK, Cancel and Help buttons. If you use TAB, the default button is always associated with OK button. Standard WinXP behaviour can be observed by some standard WinXP application. I have found a good example in Start/Programs/Accessories/AddressBook/ and there invoke Tools/Accounts... dialog. You will see after using TAB key, that default button is moving in accordance with focused button. As it seems it is standard WinXP behaviour and there is problem with L&F guidelines, commonly used in NB: "Two common exceptions are the default button (activated by hitting Enter or Return) and the Cancel button (activated by hitting Escape) - these should not have an associated mnemonic." So, this is the question for HIE team. Isn't would be better to provide mnemonics also for default button, regardless the L&F guidelines? CCing also Jano Rojcek as a member of HIE team for any comments.
Assigning TM to 4.0.
I will add a mnemonic to Find button + "Find What" and "Replace With" combos also need the mnemonics to be accessible... As for default button issue I have entered another issue #50803
Aha, using WinXP L&F on JDK 1.4.2_03, JLabels have problems with repainting, so underline after pressing ALT is not visible. Already in bugparade: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4945795 I have test it, just move the window such, that the label goes out of the sceren and then move it back (it causes repaint) and you will see mnemonics... Anyway, it works on Metal L&F on JDK 1.4.2 and the problem is fixed on JDK 1.5 on WinXP L&F also... So, I will just add a mnemonic for Find button.
fixed in [maintrunk] /cvs/editor/libsrc/org/netbeans/editor/ext/FindDialogSupport.java,v <-- FindDialogSupport.java new revision: 1.50; previous revision: 1.49
Verified in dev build 200410251800