Community
Participate
Working Groups
1) Go to "Select a profile" combo in the formatter preference page 2) Choose another profile using the UP or DOWN arrow key bug: focus is thrown to the workbench's search combo in the top left.
This is actually slightly worse than I first thought. If the user is attempting to navigate through the list of formatters using the keyboard, it is impossible because the drop down closes immediately, selecting the formatter option and throwing focus. So, between steps 1&2, insert the following 1.5) press ALT+DOWN_ARROW to open the list of formatters
see bug 59661 for more discussion on combos, using default selection, and pushing on SWT for a new "rollup" event.
I can't reproduce the focus behaviour you describe neither on 3.1.1 nor I20050928. (WinXp) On cursor down, the combo flickers, but keeps the focus. Seems to be an SWT issue.
Better steps: 1) Display the formatter prefs 2) Make sure the search combo has focus 3) Click on the formatter combo with the mouse 4) Press up/down arrow key My guess is that this has to do with deactivating and reactivating the Shell.
What does "rollup" event have to do with it? Without fighting through the code, does anyone have an idea what events are involved so I know where to start? For example, is anyone doing work on SWT.Traverse, SWT.Activate, SWT.Focus etc. If "rollup" would help, do tell.
The problem is caused by the shell becoming disabled. A rollup event would reduce how often selection changes get processed, resulting in fewer cases where the shell gets disabled, which collapses the combo and sometimes throws foucs to the wrong widget. Here's the stacktrace: Shell.setEnabled(boolean) line: 1008 ProgressManager.setUserInterfaceActive(boolean) line: 1184 ProgressManager.access$5(ProgressManager, boolean) line: 1180 ProgressManager$3.run() line: 860 BusyIndicator.showWhile(Display, Runnable) line: 69 ProgressManager.busyCursorWhile(Runnable, ProgressMonitorJobsDialog) line: 895 ProgressManager.busyCursorWhile(IRunnableWithProgress) line: 871 ProgressManager.run(boolean, boolean, IRunnableWithProgress) line: 1070 ProfileManager.flushPreferences(IEclipsePreferences) line: 562 ProfileManager.writeToPreferenceStore(ProfileManager$Profile, IScopeContext) line: 553 ProfileManager.commitChanges(IScopeContext) line: 687 CodeFormatterConfigurationBlock$StoreUpdater.update(Observable, Object) line: 84
You are asking that they change the UI metaphore for Combo in this dialog for a SWT.READ_ONLY Combo. The Combo bug 59661 refers to an editable Combo and requests behavior like IE. I'm not sure it applies. In any case, the correct SWT behavior is happening. The shell is being disabled. Therefore, the user can't interact with the Combo. That can't/shouldn't be changed so I need to mark this as WONTFIX. Thanks to Randy for chasing down the stack trace.
Steve, I think there are several potential problems/workarounds, separate from the rollup event request bugs? 1) why does Shell.setEnabled(true) restore focus to the wrong widget in the steps described in comment 4. 2) why does the Combo close when I am trying to navigate through its entired? Probably because the shell gets disabled, so this is w.a.d. workarounds? 3) Should JDT use the default selected event instead of selected event. Based on your last comment, you are saying that because the combo is not editable, then the user would not expect to have to press ENTER. Also, I agree a "reload" button won't work here. 4) Could JDT use a timer or something else to allow the user to navigate through the combo but not immediately apply the selection. 5) Send an event when the readonly combo closes, or avoid sending selection events until then. This is covered in another bug. Are 1-4 all WONTFIX?
Item 1) sounds like a bug, please open a new report. However, I'm not sure the combo actually took focus when the mouse went down so it might be platform behavior, rather than focus being restored to the wrong widget. Item 2) is the reason we have the problem in the first place and the correct resolution is WONTFIX. That's what this bug report is about and we shouldn't take any action here. Items 3) and 4) are up to the application code and have nothing to do with SWT. Item 5) is a feature request that is already being tracked by a bug report.
> Items 3) and 4) are up to the application code and have nothing to do with SWT. Which is why the bug report was filed JDT in the first place. Martin, workaround #74 would be to not use BusyCursor in flushPreferences. There is also another bug tracking the fact that the change should not be agressively saved anyway.
bug 101619 will make this go away?
fixed > 20051006 Fix for bug 101619 solves the problem.
Verified using I20051031-2000
