Community
Participate
Working Groups
Build ID: M20090211-1700 Steps To Reproduce: 1. Create a button radio group. 2. Add listeners to each button for selection. 3. Add swtbot test to execute click() on the buttons in the group. The selected button is sent a notify, the deselected buttons aren't sent a notify. More information: problem is in SWTBotRadio.click(). notify(SWT.Selection) is only sent to the clicked button, but state is possibly changed on other buttons in the group. This could also happen for menu items with style SWT.RADIO, but I haven't verified that issue. I'm going to post code that fixed the problem I was seeing.
Here is a version of the deselect in SWTBotRadio.click() that works for me. private void deselectOtherRadioButtons() { if (hasStyle(widget.getParent(), SWT.NO_RADIO_GROUP)) return; Widget[] siblings = SWTUtils.siblings(widget); for (Widget sib : siblings) { if ( widget == sib) continue; // skip the selected button if ((sib instanceof Button) && hasStyle(widget, SWT.RADIO) && ((Button)sib).getSelection()==true){ ((Button) sib).setSelection(false); sib.notifyListeners(SWT.Selection, createEvent()); } } } Another change that should be considered is changing the asyncExec in SWTBotRadio.click() to syncExec, since otherwise the notify(SWT.Selection) can occur before the widget.setSelection(true) for the selected button. I've applied both of these to my local code.
Created attachment 144986 [details] swtbot Test case for both radio button and radio menuItem Demonstrates that the radio notification for deselection is broken for both radio button groups and for radio menuItem groups.
Created attachment 145022 [details] Improvement of same test4 case to check underlying listeners The previous test only asserted for the widget display, without verifying that the underlying listener had been called. This version checks the strings that are an indication of the listener response.
Created attachment 145023 [details] Fixed version of SWTBotMenu.java, with only toggleSelection modified Change handling of toggleSelection() for handling of SWT.RADIO MenuItem. There will also need to be the accompanying change to SiblingFinder so that it handles MenuItem.
Created attachment 145024 [details] Changes to SiblingFinder to handle MenuItem SiblingFinder changes to add isMenuItem(Widget) and to handle MenuItem in run(). This is the accompanying change to fix the MenuItem handling for SWT.RADIO.
Created attachment 145027 [details] The SWTBotRadio.java with modifications to deselectOtherRadioButtons SWTBotRadio.java, modified so it fixes the problems with the Radio buttons. These attached sources were all modified from imported jar sources from SWTBot 2.0.0.371-dev-e34 download
Jay, would you be able to provide a patch instead of complete files ? It is very difficult for me to see what has changed just looking at individual files.
Jay, Ignore my previous comment for this particular bug, I'll pick this bug up for now. I noticed a block of code in the loop that iterates through siblings which does a check on the menu items parent, is there a reason why you're doing this ?
(In reply to comment #8) > Jay, > Ignore my previous comment for this particular bug, I'll pick this bug up for > now. > I noticed a block of code in the loop that iterates through siblings which does > a check on the menu items parent, is there a reason why you're doing this ? The menu items in a radio group are separated from other menu items by the dividers, and we only want to notify the listeners of other radio buttons in the same group. The parents determine the subgroup in the menu.
(In reply to comment #9) > The menu items in a radio group are separated from other menu items by the > dividers, and we only want to notify the listeners of other radio buttons in > the same group. The parents determine the subgroup in the menu. Thanks for that clarification! Would it be possible for you to use the test framework provided in swtbot to write the test case ? The existing test case that you've provided, although quite comprehensive could probably be split up into multiple tests with more meaningful test names.
(In reply to comment #10) > (In reply to comment #9) > > The menu items in a radio group are separated from other menu items by the > > dividers, and we only want to notify the listeners of other radio buttons in > > the same group. The parents determine the subgroup in the menu. > Thanks for that clarification! Would it be possible for you to use the test > framework provided in swtbot to write the test case ? The existing test case > that you've provided, although quite comprehensive could probably be split up > into multiple tests with more meaningful test names. It isn't clear to me how your framework is supposed to work. We have a lot of junit4 tests that execute in our nightly builds, and the attitude here is that the swtbot tests should be fixed so that they run with the other junit4 tests. We tested a small addition that makes that possible, but have concerns since there is no official support for that. Is there some anticipated development that will continue to add to the swtbot test framework, making it different than junit4, or is the handling of the non-gui thread requirement anticipated to be the only difference?
Has this been resolved? I seem to be seeing the same problem. Specifically, I have a dialog containing two radio buttons in a group. At runtime, everything behaves as expected: the two radio buttons are always in the opposite state. At SWTBot test time, however, the automatic de-selection mechanism implemented via notifications doesn't work, so when the test code click()s on one of the radio buttons, both radio buttons end up in the selected state.
Created attachment 187456 [details] patch file (In reply to comment #12) > Has this been resolved? I seem to be seeing the same problem. > > Specifically, I have a dialog containing two radio buttons in a group. > > At runtime, everything behaves as expected: the two radio buttons are always in > the opposite state. > > At SWTBot test time, however, the automatic de-selection mechanism implemented > via notifications doesn't work, so when the test code click()s on one of the > radio buttons, both radio buttons end up in the selected state. Adding a new attachment to clean up the radio deselection code based on the 3 source files that are obsoleted. I looked at the code and the code does seem OK. Any takes to clean up the unit tests so I can push this change in? Looking at the tests in the current state, I'm unable to make heads or tails out of what it is supposed to be doing.
Fixed in rev 1d3bdff(https://github.com/ketan/SWTBot/commit/1d3bdf). Please verify if the fix works for you.
Created attachment 189877 [details] mylyn/context/zip
(In reply to comment #14) > Fixed in rev 1d3bdff(https://github.com/ketan/SWTBot/commit/1d3bdf). Please > verify if the fix works for you. FWIW fix works for me :)
I'm concerned there's now a version incompatibility... From what I understand, the behaviour that this bug was trying to match was introduced in Eclipse 3.6, but SWTBot 2.0.4 has been introduced also for Eclipse 3.5. I'm still on Eclipse 3.5 and weird things are happening in this area, which don't happen if I disable the notification of deselected button listeners introduced here. I'd suggest either some kind of version check needs to be done, or getting SWTBot on Eclipse 3.5 should fetch 2.0.3 without this fix.
