Querying state of a radio button group

#1 Duh, I neglected to search the forums themselves, my bad. Have found some clues, will post back if I get stuck. Sorry :()

#2 Turns out that there isn't really anything specific regarding querying states of a radio button group in the forums. Has anyone worked this topic before and realized a (relatively) easy solution? I've got a possible solution coming along, but it's a lot more kludgy then I had hoped...

#3 How are they queried elsewhere in the engine? Have you looked at the C++?

#4 Yes I have, and am actually working on a mini-writup on what I found, but in a nutshell, a "pressed" radiobutton never actually reports that fact to the parent class, but does broadcast it's state to siblings. I'll provide more significant details, and how I hacked around the issue in scripting, as well as an SDK solution suggestion when I can make sure I know what I'm talking about!

The short answer is I used the button's onAction to update a global (userpref) variable, and then accessed the variable in the display control. There currently is no (obvious) way of querying a parent on the current state of it's child radiobuttons however.

#5

Quote:
There currently is no (obvious) way of querying a parent on the current state of it's child radiobuttons however.

But why would that be desirable behavior? The parent control doesn't have any reason to know about what its children are doing, especially if you have multiple sets of radio buttons...

I think I've seen implementations that tie all the radio controls to the same namespace so the same method gets called for each, just setting a different value.

#6 From a purely theoretical design perspective, if I have a set of objects that can have 1 and only 1 state (1 pressed, or worst case, none pressed), there should be an abstracted data layer where I can query which state the set is in...in other words, a container for the radio buttons which has a state derived from the underlying button states. From a pure abstraction layer, I should be able to query the container holding the buttons (the parent, in this case) to determine the state of said container--and I should most definitely -not- be able to query the buttons themselves.

The current implementation as far as I can tell has the radio buttons communicating at the sibling layer, but there is no reference to the state of the set at a container level (the parent)--other than iterating over the children of the container, I have no way to query the set state. In other words...what good are radio buttons? Sure, I can press them, but there is no way for them to (as an abstract data layer) provide me information.

I'm being pedantic here I know...data abstraction is one of my pet peeves, so let me try to describe it a bit more fundamentally.

A radio button has no functionality by itself--it's simply a check box. The functionality specific to the concept of a radio button comes from it being a part of a set of radio buttons, with the property of only one of the buttons may be selected at any given state. If I am in a situation where I want to use the concept of radio buttons, it means that, given a set of options, only one of that set may be in the "set" state. To easily use this data structure, I should be able to query the set as a whole to determine which button is pushed. The Torque SDK implements the "only one set at a time" state rather well, but it doesn't provide an abstracted way to determine the state of the set of buttons--I have to directly access the buttons themselves (or set a variable external to the data structure during activation--this is the solution I used to solve my problem). As an abstract data class, I shouldn't have to do that.

It's a minor point, hehe...and pretty esoteric when it comes down to it, but hey, data abstraction is where OOP started off!

Secondary Edit: I'm new to Torque, but as far as I can tell, the groupNum relationship actually has no bearing in the data abstraction for radio buttons. The first differentiated implementation is at the GuiButtonBaseCtrl::onAction(), when mButtonType = ButtonTypeRadio, and all it does is messageSiblings to turn them off after setting it's state to on. As far as I can see, the groupNum, while stored, actually has no bearing on the button/container set implementation. From a purely theoretical standpoint, this is good! A radio button group container should only have one group of radio buttons, lol...but it means that the variable has no effect.

#7 The solution you used is probably the best one. Easy to implement and maintain. The way Torque is means you can use the radio buttons for other stuff if the mood ever strikes you, too.

Anyway, you'll find most of the stuff in Torque is good enough to write a good, commercial-quality game with. If you want to write neat abstraction layers rather than games, go for it... :)

#8 Personally, I see this as a -way low- priority situation. It would be -nice- to instantiate a set of radio buttons as a container class, and be able to directly query the state of the button set by messaging the container, but like you said, it's really not that big a deal.

I don't really ever see the Torque dev staff so bored they need to implement abstraction stuff, but if they are...this is a good one ;)

#9 Yep, over engineering, over oopifying.. :)

Dont.. forget it.. not worth even doing.

#10 I'm going to go with Stephen on this one.

As a serious game devloper, I came across this forum because I was looking for this type of functionality. It would be helpful to have now that I am creating guis that are a little bit more in depth than your average game's.

I agree with you though Ben, if I really needed it, I can do it myself. I'll put it on my to do list.

#11 I had to touch a lot of controls from GuiControl on down and made sure that all the controls worked the same way, had methods for handling commands, variables, state changes, etc. for obvious OOP reasons. Also, not all controls handle disable states or "grey" properly. I've built several "complex" controls that incorporate subclassed versions of other controls. I've not looked at the 1.4 Gui Controls yet, but I hope they're friendlier.

#12 *BUMP*

So, I'm playing with guiRadioCtrl to clean up a couple of my GUIs (popUpMenu's everywhere).

I have three buttons (GuyRadio, GirlRadio, KidRadio) in a group (1). I need to assign a player "class" based on which radio is selected.

Instead of doing something like this:

function assignClass()
{
    %bGuyPicked = GuyRadio.getValue();
    %bGirlPicked = GirlRadio.getValue();
    %bKidPicked = KidRadio.getValue();
   
   if(%bGuyPicked)
   {
      echo("Guy Picked");
   }
   else if(%bGirlPicked)
   {
      echo("Girl Picked");
   }
   else if(%bKidPicked)
   {
      echo("Kid Picked");
   }
   else
   {
      echo("You are screwed! Because no one is picked!");
   }
}

I'd much rather do something like this:

// Pass in group number of radio group, returns name of selected radio
%selectedRadio = getSelectedRadio(1);

switch$(%selectedRadio)
{
    case "GuyRadio":
         echo("Guy Picked");

    case "GirlRadio":
         echo("Girl Picked");

    case "KidRadio"):
         echo("Kid Picked");
}

So. . . .has anyone done this, yet? Or should I get on it, code it, and submit the resource?