Community
Participate
Working Groups
Created attachment 287794 [details] Snippet to recreate issue. Use Eclipse 4.12+ to run workflow as dscribed ======= Summary ======= In our solution we're using a radio button control group with a "OFF" and "ON" radio button. When selecting the "ON" radio button, it triggers a dialog (inner dialog) to launch via selection event tied to the "ON" button. When closing the launched dialog (inner dialog), a callback function is used to reset the currently selected "ON" button back to "OFF". In Eclipse 4.10 this worked fine, but when upgrading to Eclipse 4.16 the dialog is getting relaunched. The introductory change is either Eclipse 4.11 or 4.12 (thinking the latter because of some modal changes listed for that version). One thing that was noticed debugging was that the callback correctly toggles the radio button selected to "OFF", but then shortly after a separate focus event resets (and selects) the "ON" button. The "ON" button has the selection event to launch dialog - meaning the dialog relaunches. By placing breakpoint on the Button.setSelection() method, we get a stack trace where it seems shell.WM_ACTIVATE will try to restore focus to the wrong radio button with the restoreFocus() method. we don't seem to be getting the same call stack at all on older versions (4.10 Eclipse). Pasted stack trace for this at the bottom of this comment. ======================= Steps to Recreate Issue ======================= Run the attached snippet using eclipse 4.12+ 1. Select "ON" button to launch dialog 2. Select the "Select 'off' and Close" button 1. Expected: Dialog closes and the radio button selected is the "OFF" button (This is what happens when running Eclipse 4.10) 2. Actual: Dialog relaunches and focus is on the "ON" button (Happens with Eclipse 4.12+) =========== Stack Trace =========== Thread [main] (Suspended (breakpoint at line 982 in Button)) Button.setSelection(boolean) line: 982 Button.setRadioSelection(boolean) line: 959 Button.selectRadio() line: 737 Button.wmCommandChild(long, long) line: 1284 Composite(Control).WM_COMMAND(long, long) line: 4891 Composite(Control).windowProc(long, int, long, long) line: 4743 Display.windowProc(long, long, long, long) line: 4931 OS.CallWindowProc(long, long, int, long, long) line: not available [native method] Button.callWindowProc(long, int, long, long) line: 255 Button(Widget).wmSetFocus(long, long, long) line: 2215 Button(Control).WM_SETFOCUS(long, long) line: 5421 Button.WM_SETFOCUS(long, long) line: 1190 Button(Control).windowProc(long, int, long, long) line: 4812 Display.windowProc(long, long, long, long) line: 4923 OS.SetFocus(long) line: not available [native method] Button(Control).forceFocus() line: 1105 Button(Control).setFocus() line: 3440 Button.setFocus() line: 864 Shell(Decorations).restoreFocus() line: 761 Shell(Decorations).WM_ACTIVATE(long, long) line: 1525 Shell.WM_ACTIVATE(long, long) line: 2170 Shell(Control).windowProc(long, int, long, long) line: 4737 Shell(Canvas).windowProc(long, int, long, long) line: 340 Shell(Decorations).windowProc(long, int, long, long) line: 1480 Shell.windowProc(long, int, long, long) line: 2142 Display.windowProc(long, long, long, long) line: 4923 OS.DestroyWindow(long) line: not available [native method] Shell(Control).destroyWidget() line: 786 Shell.destroyWidget() line: 710 Shell(Widget).release(boolean) line: 804 Shell(Widget).dispose() line: 410 Shell(Decorations).dispose() line: 392 Shell(Decorations).closeWidget() line: 270 Shell.close() line: 548 Snippet$1$1.widgetSelected(SelectionEvent) line: 48 TypedListener.handleEvent(Event) line: 252 EventTable.sendEvent(Event) line: 89 Display.sendEvent(EventTable, Event) line: 4213 Button(Widget).sendEvent(Event) line: 1037 Display.runDeferredEvents() line: 4030 Display.readAndDispatch() line: 3630 Snippet.main(String[]) line: 59
There is a similar issue with your code when you select 'off' instead of using the close button. From the documentation of addSelectionListener in Button: * When the <code>SWT.RADIO</code> style bit is set, the <code>widgetSelected</code> method is * also called when the receiver loses selection because another item in the same radio group * was selected by the user. During <code>widgetSelected</code> the application can use * <code>getSelection()</code> to determine the current selected state of the receiver. However you are calling the code programmatically, then the question is if the event should be raised. i.e. 'selected by the user' is not true. In fact, it seems opposite to the behavior as observed in Bug 577860, where the event is not raised when the selection is changed on a checkbox programmatically.
This is a regression from Bug 297510, together with 'Feature in Windows' see Button#setFocus(). When the shell is activated, it tries to restore the focus to the previous selected control. In this case it is the 'On' radio button. When this button gets focus, windows selects the button, which re-opens the shell in this case.
Bug 297510 removed setSavedFocus, which had a check to prevent the selection of the radio button. Bug 328290 removed setFixedFocus, and moved a similar check to setFocus, but it only executes in the set-fixed case. To do this check also in case of saved-focus was missed in Bug 297510. However, I believe that this check is always relevant, so no conditions are needed.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189613
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189613 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=21ec140564867375b8b5d69a07b0548cd33cba0f
(In reply to Eclipse Genie from comment #5) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189613 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=21ec140564867375b8b5d69a07b0548cd33cba0f Thanks Rolf for the fix, resolving now.
Verified on Win10 using Eclipse Build id: I20220216-1800
