Community
Participate
Working Groups
Most newer Windows mouse drivers support an option to: "Automatically moves the pointer to the default button in a dialog box" This seems to work in most applications, however, we do not honour it in Eclipse. I tried it with the "Bad number" error prompter in the filter dialog (I was told this was a real honest to goodness OS dialog) and it did not work.
It's not even clear to me how we could *stop* this from working. To be fixed post R2.0.
*** Bug 17927 has been marked as a duplicate of this bug. ***
This is now honoured in dialogs for default buttons (control with the Windows window class "BUTTON") that are direct children of a dialog shell. Windows mouse drivers detect this case and acts accordingly. On Windows, dialogs are typically created from resource files where the widget tree is exactly one level deep. Eclipse on the other hand, tends to build hiearchies of widgets. Unfortunately, I could not find a way to convince the Windows mouse driver to look into a hierarchy of widget for the default button. Here is some code that shows this feature working: public static void main200 (String [] args) { Display display = new Display (); Shell shell = new Shell (display); shell.pack (); shell.open (); Shell dialog = new Shell (shell, SWT.DIALOG_TRIM); Label label = new Label (dialog, SWT.NONE); label.setText ("Exit the application?"); Button okButton = new Button (dialog, SWT.PUSH); okButton.setText ("&OK"); Button cancelButton = new Button (dialog, SWT.PUSH); cancelButton.setText ("&Cancel"); FormLayout form = new FormLayout (); form.marginWidth = form.marginHeight = 8; dialog.setLayout (form); FormData okData = new FormData (); okData.top = new FormAttachment (label, 8); okButton.setLayoutData (okData); FormData cancelData = new FormData (); cancelData.left = new FormAttachment (okButton, 8); cancelData.top = new FormAttachment (okButton, 0, SWT.TOP); cancelButton.setLayoutData (cancelData); dialog.setDefaultButton (okButton); dialog.pack (); dialog.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); }
I'm sorry but Eclipse dialogs need to be changed so the default button is a direct child of the shell. It turns out that screen readers such as JAWS expect this structure anyways so this change may be necessary anyways. I'm adding 15559 to the dependency list even though they are not stictly related. In order to fix both problems, Eclipse dialogs need to be rewritten.
Moving to UI.
BUGZILLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLAAAHHHHHHHHHHHHHH!!!!!!!!!!!
This would be a post 2.1 change as it would break all current dialogs.
Can you explain it a little bit more detailed please? I can't understand why this would break all dialogs? From my understanding the mouse pointer simple needs to jump to the default button if a new dialog box pops up and has focus. I havn't developed with dialog boxes yet but from the things I seen so far, there is already the posibility of defining a default button in dialogs. Thus, there is no API change. The only change should be in the native Win32 SWT code calling Windows API because this "jump" is a windows setting and should never be turned of by applications. A possible fix shouldn't change any public or protected Java API used by other (external) applications developed using SWT (like Eclipse). This bug reduces usability in a way that is not suitable for 32bit Windows applications using "native Win32 API". I'd like to have the severity at least set to "normal".
Has anyone done some changes in 2.0.1 branch?
Gunnar, please re-read my comments from 2002-07-04 12:10 describing how "move to default button" is implemented by Windows. We are currently restricted to the support provided by Windows. The summary is, "no API change is necessary in SWT but Eclipse dialogs need to be recoded so that push buttons are the direct children of a dialog shell".
The breaking change is the removal of the buttonBar Composite in dialogs. Currently code is written assuming the existance of the button bar when adding in your buttons. We could rework this but it would require API changes that will break existing dialogs. This is also an accessibility issue BTW.
*** Bug 28351 has been marked as a duplicate of this bug. ***
Any news? I suggest a reassessment of the severity and the priority. This is a MUST-FIX for 3.0 because it is really bad UI. Is it possible to implement this above the native layer? I saw OpenOffice has a switch for that (do nothing/jump to dialog center/jump to default button) that works on multiple platforms. The SWT shell might get such a switch and the "jump to" functionallity is emulated via positioning the mouse pointer on all platforms. I don't know.
*** This bug has been marked as a duplicate of 67031 ***
