1. Win32LIb: setCheck anomaly?
Using Win32Lib 0.60.6, when I use setCheck on one radio control in a group of
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
2. Re: Win32LIb: setCheck anomaly?
Dan Moyer wrote:
>
> Using Win32Lib 0.60.6, when I use setCheck on one radio control in a group of
> 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.
CChris
3. Re: Win32LIb: setCheck anomaly?
CChris wrote:
>
> Dan Moyer wrote:
> >
> > Using Win32Lib 0.60.6, when I use setCheck on one radio control in a group
> > of
> > 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
4. Re: Win32LIb: setCheck anomaly?
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
> > > 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
Yep, not too difficult actually (duplicate the menu item code and change
the menu specific part).
Btw, you may have peeked at the change log in various files you got a
link to. Any feedback?
CChris
5. Re: Win32LIb: setCheck anomaly?
- Posted by Derek Parnell <ddparnell at bigpond.com>
Feb 28, 2007
-
Last edited Mar 01, 2007
CChris wrote:
> Btw, you may have peeked at the change log in various files you got a
> link to. Any feedback?
Sort of ... haven't seen it all yet ... I'm testing out the docs at the moment
and the library by trying to write an real-world application. So far, I've found
the docs very poor (yes - I did write most of them) and there is some needed
functionality that is just not there.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
6. Re: Win32LIb: setCheck anomaly?
- Posted by CChris <christian.cuvier at agriculture.gouv.fr>
Feb 28, 2007
-
Last edited Mar 01, 2007
Derek Parnell wrote:
>
> CChris wrote:
>
> > Btw, you may have peeked at the change log in various files you got a
> > link to. Any feedback?
>
> Sort of ... haven't seen it all yet ... I'm testing out the docs at the moment
> and the library by trying to write an real-world application. So far, I've
> found
> the docs very poor (yes - I did write most of them) and there is some needed
> functionality that is just not there.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
Good. As you could see, I have started adding some; I don't know what your
precise plans/requirements are.
Hopefully I have a file ready for 03/20 or something with the last batch of
additions I planned. Afrer that, I'll only fix things as needed, and didn't
get many reports (could be a good sign 
)
I do have other ideas as well, but there has to be
some assessment of where the library wants to go before coding these.
I didn't add any example to the routines I coded because simple examples are
lame and uninformative, while useful examples are often more complex and
tedious to describe thoroughly. Not a good idea admittedly, but I didn't
come up with anything better so far.
Perhaps the docs could enable one to launch demos; that might help in more
than a few cases. But I'm fully aware of how tedious that is...
CChris
7. Re: Win32LIb: setCheck anomaly?
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
> > > 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
8. Re: Win32LIb: setCheck anomaly?
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
> > > > 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
9. Re: Win32LIb: setCheck anomaly?
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
10. Re: Win32LIb: setCheck anomaly?
Dan Moyer wrote:
> 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?
Yes. The Window is like a default Group control and all radio buttons directly
on the Window should behave as if they were in the same Group.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
