Re: Win32LIb: setCheck anomaly?
- Posted by Dan Moyer <danielmoyer at prodigy.net> Mar 02, 2007
- 517 views
CChris wrote: > > Dan Moyer wrote: > > > > Derek Parnell wrote: > > > > > > CChris wrote: > > > > > > > > Dan Moyer wrote: > > > > > > > > > > Using Win32Lib 0.60.6, when I use setCheck on one radio control in a > > > > > group > of</font></i> > > > > > radios, > > > > > it does NOT clear any other radio that might be checked. > > > > > > > > > > So if a radio in the group is checked, and the program sets another > > > > > one > > > > > with setCheck, I end up with TWO radios in the same group checked. > > > > > > > > > > It does set the specified radio, and user manually clicking on any > > > > > radio > > > > > will reset any other that's checked. And of course I can & now did > > > > > programmatically reset all radios before setChecking any, but it was > > > > > an > > > > > unexpected behaviour. > > > > > > > > > > Dan Moyer > > > > > > > > Well setCheck() just sets the checked state, so the behaviour is not > > > > unexpected, just annoying. > > > > What could be missing in the lib is a defineButtonRadioGroup() akin to > > > > defineMenuRadioGroup(). And setCheck() would have to care for them as it > > > > > > > > currently does for menu radio groups. > > > > > > This is a bug. All radio buttons in the same group are supposed to be > > > mutually > > > exclusive, meaning that only one can be checked at any time. When the user > > > clicks > > > on one the others are meant to get automatically unchecked. > > > > > > Another thing to fix > > > > > > -- > > > Derek Parnell > > > Melbourne, Australia > > > Skype name: derek.j.parnell > > > > Derek, > > > > You may have completely & correctly understood me, but just to be sure: > > the radios DO work correctly when a USER *CLICKS* on them; > > it's only when *SETCHECK* is encountered in a program that > > the radios don't clear properly. > > > > Dan > > Confirmed. > My plan for this is threefold: > * in openWindow(), check that no two radios in any given group which has the > current window as ancestor are checked; if so, choose one (the init focus > should be prioritised). Record for each group the checked radio it has or 0. > > Going through openWindow() is necessary to handle any erroneous checking > pattern in a form based control. > * in setCheck(), if there's a parent group and if another radio there is > checked, uncheck it. Update checked button in group. > * If a radio button in a group gets a w32HClick event, perform same check. > > CChris CChris, Not sure I understand about going through openWindow() re form based controls, but I assume you're right. However, just checking if a radio is in a GROUP may not be sufficient, because radios that are NOT placed in a group, ie, just some in a WINDOW, are supposed to have the same EXCLUSIVITY as ones in a group, so that the window is "like" a group for the radio controls. Right? Dan Moyer