Community
Participate
Working Groups
Build Identifier: Build id: 20100218-1602 In this scenario, none of the radio button are selected by default. If the radio button are on a Composite created by new Composite, then it all works as expected. If the radio button are on a Composite created by toolkit.createComposite, then if you clock anywhere on the composite, the first radio button will be selected. I believe this is because the adapt() method in the FormToolkit add a MouseDown listener to the Composite. The listener then call setFocus on the first control of the form. If this is a radio button in a group where there is no selection, the first button gets selected. Suggest to not calll setFocus() in that particular context, or use forceFocus on the Composite itself. Reproducible: Always Steps to Reproduce: Attaching code sample project com.jmp.demo.project.zip. Code is in ApplicationWorkbenchWindowAdvisor::createWindowContents( shell ).
Created attachment 189001 [details] Example to replicate the problem See code in ApplicationWorkbenchWindowAdvisor::createWindowContents(Shell shell).
This is working as designed. Composites and other controls created by FormToolkit are "adapted" which involves setting the background color and adding a mouse down listener which sets focus. If you want to set the background but not add the listener you can use this kind of sequence: Composite rbc2 = new Composite(parent, SWT.BORDER); toolkit.adapt(rbc2, false, false);
I would argue the problem is with the `mouse down listener which sets focus`. If the controls on the composite are radio button, and none are selected, setting the focus on a radio button of the group will select the first radio button which is not what the user intended. I would suggest that in that particular case, no focus change is made. Thoughts ?
I don't want to change the current behavior because that would affect the way existing applications work. I agree with you that in the case of Radio buttons this causes some odd side effects but there is a workaround. I did not write the original code and had I done so I probably would not have added the mouse click listener, having said that I would rather leave the current behavior as is since it has been that way for a long time.
Understood... That is a better answer than `working as designed`. Work around does not quite work with us for some other reasons, but feel free to close. Thanks JM
