Re: Win32LIb: setCheck anomaly?

new topic     » goto parent     » topic index » view thread      » older message » newer message

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 blink
> > > 
> > > -- 
> > > 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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu