Community
Participate
Working Groups
F1+ I need question dialog with No as the default button. I create the dialog with MessageDialog dialog = new MessageDialog( fParent, getDialogTitle(), null, RefactoringMessages.getString ("SurroundWithTryCatchAction.no_exceptions"), //$NON-NLS-1$ MessageDialog.QUESTION, new String[] {IDialogConstants.YES_LABEL, IDialogConstants.NO_LABEL}, 1); But the Yes button is still the default button. Problem is that SWT set the focus to the first button when a shell gets opened. This also makes it the default button. Here is that stack trace: Thread [main] (Suspended (breakpoint at line 747 in org.eclipse.swt.widgets.Decorations)) org.eclipse.swt.widgets.Shell (org.eclipse.swt.widgets.Decorations).setDefaultButton (org.eclipse.swt.widgets.Button, boolean) line: 747 org.eclipse.swt.widgets.Button.WM_SETFOCUS(int, int) line: 618 org.eclipse.swt.widgets.Button (org.eclipse.swt.widgets.Control).windowProc(int, int, int) line: 2714 org.eclipse.swt.widgets.Display.windowProc(int, int, int, int) line: 1984 org.eclipse.swt.internal.win32.OS.SetFocus(int) line: not available [native method] org.eclipse.swt.widgets.Button (org.eclipse.swt.widgets.Control).forceFocus() line: 566 org.eclipse.swt.widgets.Button(org.eclipse.swt.widgets.Control).setFocus () line: 1891 org.eclipse.swt.widgets.Button.setFocus() line: 434 org.eclipse.swt.widgets.Button (org.eclipse.swt.widgets.Control).setTabItemFocus() line: 2186 org.eclipse.swt.widgets.Button (org.eclipse.swt.widgets.Control).setTabGroupFocus() line: 2181 org.eclipse.swt.widgets.Shell (org.eclipse.swt.widgets.Control).traverseGroup(boolean) line: 2523 org.eclipse.swt.widgets.Shell.open() line: 613 org.eclipse.jface.dialogs.MessageDialog (org.eclipse.jface.window.Window).open() line: 534 org.eclipse.jdt.ui.actions.SurroundWithTryCatchAction$Query.catchRuntime Exception() line: 68 org.eclipse.jdt.internal.corext.refactoring.surround.SurroundWithTryCatc hAnalyzer.endVisit(org.eclipse.jdt.core.dom.CompilationUnit) line: 81 org.eclipse.jdt.core.dom.CompilationUnit.accept0 (org.eclipse.jdt.core.dom.ASTVisitor) line: 147 org.eclipse.jdt.core.dom.CompilationUnit (org.eclipse.jdt.core.dom.ASTNode).accept(org.eclipse.jdt.core.dom.ASTVisitor) line: 1330 org.eclipse.jdt.internal.corext.refactoring.surround.SurroundWithTryCatc hRefactoring.checkActivationBasics(org.eclipse.jdt.core.dom.CompilationUnit, org.eclipse.core.runtime.IProgressMonitor) line: 113 org.eclipse.jdt.internal.corext.refactoring.surround.SurroundWithTryCatc hRefactoring.checkActivation(org.eclipse.core.runtime.IProgressMonitor) line: 130 org.eclipse.jdt.ui.actions.SurroundWithTryCatchAction.run (org.eclipse.jface.text.ITextSelection) line: 90 org.eclipse.jdt.ui.actions.SurroundWithTryCatchAction (org.eclipse.jdt.ui.actions.SelectionDispatchAction).dispatchRun (org.eclipse.jface.viewers.ISelection) line: 180 org.eclipse.jdt.ui.actions.SurroundWithTryCatchAction (org.eclipse.jdt.ui.actions.SelectionDispatchAction).run() line: 156 org.eclipse.jdt.ui.actions.SurroundWithTryCatchAction (org.eclipse.jface.action.Action).runWithEvent(org.eclipse.swt.widgets.Event) line: 590 org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (org.eclipse.swt.widgets.Event) line: 407 org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (org.eclipse.swt.widgets.Event) line: 361 org.eclipse.jface.action.ActionContributionItem.access$0 (org.eclipse.jface.action.ActionContributionItem, org.eclipse.swt.widgets.Event) line: 352 org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEve nt(org.eclipse.swt.widgets.Event) line: 47 org.eclipse.swt.widgets.EventTable.sendEvent (org.eclipse.swt.widgets.Event) line: 75 org.eclipse.swt.widgets.MenuItem (org.eclipse.swt.widgets.Widget).sendEvent(org.eclipse.swt.widgets.Event) line: 825 org.eclipse.swt.widgets.Display.runDeferredEvents() line: 1527 org.eclipse.swt.widgets.Display.readAndDispatch() line: 1289 org.eclipse.ui.internal.Workbench.runEventLoop() line: 1085 org.eclipse.ui.internal.Workbench.run(java.lang.Object) line: 1068 org.eclipse.core.internal.boot.InternalBootLoader.run(java.lang.String, java.net.URL, java.lang.String, java.lang.String[], java.lang.Runnable) line: 739 org.eclipse.core.boot.BootLoader.run(java.lang.String, java.net.URL, java.lang.String, java.lang.String[]) line: 432 EclipseRuntimeLauncher.main(java.lang.String[]) line: 24
May be related to Bug 16254
Eduardo, is this the same problem that you had with the error dialog? Please reassign to SWT if so.
Yes, this is the same problem. The initial attempt to fix it was to set the focus to the default button if it was not set to anything else. SWT should/could set the focus to the default button if it has to be set to a button. See bug 14668
The initial focus should -not- be set to the button, even if it is the default. Almost all our dialogs rely on the initial focus being the first control in the shell that can take it.
Not sure if there is anything we can do about this. SN to investigate.
I don't think this is critical for 2.0, and is a potentially risky change to SWT. I suggest we defer it.
This is not an SWT problem. On most platforms including Windows, when a button gets focus, it becomes the default button, temporarily clearing the original default button until focus is lost to another widget that is not a button. Here is what SWT would have to do: Detect the case when no initial focus has been set in the shell and there are only button widgets in the shell and the application has defined a default button, then set focus to that button. Not a good thing for a portable widget toolkit to do. The correct thing is for the application code to always set focus to the control that should have focus before the shell opens. In this case, the control would be the default button.
Reopened and moved back to Workbench. IMO for message dialogs the corresponding code could set the focus to the provided default button and everything should work.
MessageDialog allows subclasses to add extra controls before the buttons by overriding createCustomArea. In the SDK there are several subclasses which do this. If we changed it to set focus on the default button, then that could potentially break the initial focus for these subclasses. Defering to post 2.0.
Reopened for investigation
I don't see us fixing this and potentially breaking so many downstream clients. Given the age of the bug, marking as WONTFIX. Please reopen if you disagree.
