Silly question regarding Radio Buttons
in [MFC]
|
Prev: Building a Mobile or Embedded Device/System? Tell VDC about your experiences for a chance to Win!
Next: How to maintain consistency with MFC-Macros
From: Cameron_C on 18 May 2010 09:16 Hello guys, I am having difficulty in understanding programatic selection of Radio Buttons. I have met with limited success in selecting/delselecting a Radio Button in a group, using SetCheck (BST_CHECKED) or SetCheck(BST_UNCHECKED). I mean the target button state ALWAYS changes. However, it appears that sometimes, the other members in the group are not reset, so I end up with more that one Radio Button showing it has been selected, or noe are selected. I suspect this occurs because I am using SetCheck. Am I misusing SetCheck? Or am I misunderstading how it should be used? What I have ended up doing out of frustration, is to make sure when I select a radio button in a group, I also deselect all of the others. And again, this is not a pressing issue. Think of it more as a frustrating User experience. It seems to me that if one button is selected, then all others should be deselected. Obviously, this is not how deselection would work, since MFC could not predict which item to select if one entry is deselected. Anyway, I am confused. Thanks for any info.
From: Goran on 18 May 2010 10:19 On May 18, 3:16 pm, Cameron_C <Camer...(a)discussions.microsoft.com> wrote: > Hello guys, > I am having difficulty in understanding programatic selection of Radio > Buttons. > I have met with limited success in selecting/delselecting a Radio Button in > a group, using SetCheck (BST_CHECKED) or SetCheck(BST_UNCHECKED). > I mean the target button state ALWAYS changes. However, it appears that > sometimes, the other members in the group are not reset, so I end up with > more that one Radio Button showing it has been selected, or noe are selected. > I suspect this occurs because I am using SetCheck. > Am I misusing SetCheck? Or am I misunderstading how it should be used? > What I have ended up doing out of frustration, is to make sure when I select > a radio button in a group, I also deselect all of the others. > > And again, this is not a pressing issue. Think of it more as a frustrating > User experience. > It seems to me that if one button is selected, then all others should be > deselected. > Obviously, this is not how deselection would work, since MFC could not > predict which item to select if one entry is deselected. Anyway, I am > confused. Radio buttons need to be in a "group" to work correctly. In resource editor, set "Group" property of your first radio button to "true". Set other buttons to "false", and set "Group" property of the control that follows the last button (in the tab order) to true. That control marks the end of the group of buttons. Your buttons will now work as desired. Goran.
From: Joseph M. Newcomer on 18 May 2010 11:20 Radio buttons do not have an obvious interface. If you have auto-radio-buttons, then when you click in a radio button group (the UI scans backward to the first control in Z-order that has the WS_GROUP settring, and that button is included, and scans forward until it falls off the end of the Z-order or hits a control with the WS_GROUP flag set, and that button is NOT included) and essentially does a SetCheck(BST_UNCHECKED) on each button in the group. Then it does a SetCheck(BST_CHECKED) on the button you clicked on. On OnBnClicked notification for that button is activated (even if the button was already checked!). But note that it explicitly does a SetCheck(BST_UNCHECKED) on every other radio button. If you explicitly call SetCheck(BST_CHECKED) on a radio button, it merely checks it. It does not uncheck other buttons in the group. The most common way of selecting a radio button is to use CheckRadioButtons in the parent (the CFormView or CDialog-derived class). This is a bit clunky also, and is of the form CheckRadioButtons(low, high, desired); but you have to know which symbol is the lowest-numbered symbol, which symbol is the highest-numbered symbol, and which symbol you want; for example I might do RegistryInt size(IDS_REGISTRY_LAST_SIZE); size.load(); CheckRadioButtons(IDC_SMALL, IDC_LARGE, size.value); which uses my Registry library to retrieve a value. This is actually a bit hokey because it assumes that I stored the size as a control ID, which actually isn't Best Practice, but I didn't want to confuse everything by using a typedef enum and decoding it to a button in this example. But if I were to renumber the buttons (which actually does happen in practice) this code would not work right. But CheckRadioButtons will uncheck all the buttons in thr range low..high and then check the button which is desired. Radio buttons are the single worst control to manage in MFC (or in Windows generally), but particularly in MFC where you cannot create control variables for the buttons, due to terminal brain damage in the design of the dialog editor. If you have to go back and add a new button to the group, you end up having to hand-edit the resource.h file! This is not really an ideal situation. But the "auto" part of auto-radio-button applies only to actual mouse clicks, and not to programmatic setting of the state. joe On Tue, 18 May 2010 06:16:01 -0700, Cameron_C <CameronC(a)discussions.microsoft.com> wrote: >Hello guys, >I am having difficulty in understanding programatic selection of Radio >Buttons. >I have met with limited success in selecting/delselecting a Radio Button in >a group, using SetCheck (BST_CHECKED) or SetCheck(BST_UNCHECKED). >I mean the target button state ALWAYS changes. However, it appears that >sometimes, the other members in the group are not reset, so I end up with >more that one Radio Button showing it has been selected, or noe are selected. >I suspect this occurs because I am using SetCheck. >Am I misusing SetCheck? Or am I misunderstading how it should be used? >What I have ended up doing out of frustration, is to make sure when I select >a radio button in a group, I also deselect all of the others. > >And again, this is not a pressing issue. Think of it more as a frustrating >User experience. >It seems to me that if one button is selected, then all others should be >deselected. >Obviously, this is not how deselection would work, since MFC could not >predict which item to select if one entry is deselected. Anyway, I am >confused. > >Thanks for any info. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Cameron_C on 18 May 2010 12:04 Thank you Joe. That was exactly what I needed to know. That the "auto" part of auto-radio-buttons does not apply to programattic selection of the buttons. And to be honest, I have avoided the CheckRadioButtons call, because I could never be sure that the Control IDs were sequential, unless I hand massaged the resource file. "Joseph M. Newcomer" wrote: > Radio buttons do not have an obvious interface. If you have auto-radio-buttons, then when > you click in a radio button group (the UI scans backward to the first control in Z-order > that has the WS_GROUP settring, and that button is included, and scans forward until it > falls off the end of the Z-order or hits a control with the WS_GROUP flag set, and that > button is NOT included) and essentially does a SetCheck(BST_UNCHECKED) on each button in > the group. Then it does a SetCheck(BST_CHECKED) on the button you clicked on. On > OnBnClicked notification for that button is activated (even if the button was already > checked!). But note that it explicitly does a SetCheck(BST_UNCHECKED) on every other > radio button. If you explicitly call SetCheck(BST_CHECKED) on a radio button, it merely > checks it. It does not uncheck other buttons in the group. > > The most common way of selecting a radio button is to use CheckRadioButtons in the parent > (the CFormView or CDialog-derived class). This is a bit clunky also, and is of the form > CheckRadioButtons(low, high, desired); > but you have to know which symbol is the lowest-numbered symbol, which symbol is the > highest-numbered symbol, and which symbol you want; for example I might do > > RegistryInt size(IDS_REGISTRY_LAST_SIZE); > size.load(); > CheckRadioButtons(IDC_SMALL, IDC_LARGE, size.value); > > which uses my Registry library to retrieve a value. This is actually a bit hokey because > it assumes that I stored the size as a control ID, which actually isn't Best Practice, but > I didn't want to confuse everything by using a typedef enum and decoding it to a button in > this example. But if I were to renumber the buttons (which actually does happen in > practice) this code would not work right. But CheckRadioButtons will uncheck all the > buttons in thr range low..high and then check the button which is desired. > > Radio buttons are the single worst control to manage in MFC (or in Windows generally), but > particularly in MFC where you cannot create control variables for the buttons, due to > terminal brain damage in the design of the dialog editor. If you have to go back and add > a new button to the group, you end up having to hand-edit the resource.h file! This is > not really an ideal situation. > > But the "auto" part of auto-radio-button applies only to actual mouse clicks, and not to > programmatic setting of the state. > joe > > On Tue, 18 May 2010 06:16:01 -0700, Cameron_C <CameronC(a)discussions.microsoft.com> wrote: > > >Hello guys, > >I am having difficulty in understanding programatic selection of Radio > >Buttons. > >I have met with limited success in selecting/delselecting a Radio Button in > >a group, using SetCheck (BST_CHECKED) or SetCheck(BST_UNCHECKED). > >I mean the target button state ALWAYS changes. However, it appears that > >sometimes, the other members in the group are not reset, so I end up with > >more that one Radio Button showing it has been selected, or noe are selected. > >I suspect this occurs because I am using SetCheck. > >Am I misusing SetCheck? Or am I misunderstading how it should be used? > >What I have ended up doing out of frustration, is to make sure when I select > >a radio button in a group, I also deselect all of the others. > > > >And again, this is not a pressing issue. Think of it more as a frustrating > >User experience. > >It seems to me that if one button is selected, then all others should be > >deselected. > >Obviously, this is not how deselection would work, since MFC could not > >predict which item to select if one entry is deselected. Anyway, I am > >confused. > > > >Thanks for any info. > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm > . >
From: David Ching on 18 May 2010 13:42
"Cameron_C" <CameronC(a)discussions.microsoft.com> wrote in message news:8B1F94DE-57E8-4091-BAA4-4AED8ECB0F06(a)microsoft.com... > That the "auto" part of auto-radio-buttons does not apply to programattic > selection of the buttons. > And to be honest, I have avoided the CheckRadioButtons call, because I > could > never be sure that the Control IDs were sequential, unless I hand massaged > the resource file. > Ahem... dare I say DDX data variables work great with radio buttons; it assigns an int member variable which you give a 0-based number to assign check the radio button within a group. -- David |