It's Save time and I have a radio button group that has no value selected. This is proper given the business rules but on the Maintain side of the house I need to capture that the field has nothing selected and therefore save a null or a zero in the associated column in the data table. When I use the widget's Maintain representation --

Frm_Applicant_Information.rbTG.ListItems.FocIndex

. . . in my Maintain code I get a value back of 1 in spite of not having the first radio button selected. Why? Should I not receive a zero? Is there another way to refer to the radio group that allows me to see that all of the values are not checked?

J.

This message has been edited. Last edited by: John_Edwards,

John,

You could use JavaScript to loop through the radio button collection and set a flag to pass back to maintain as a hidden input.

But, perhaps you should be using a collection of check boxes, not radio buttons, which imply one selection regardless of implementation. I've read that unchecked radio buttons are not submitted, but maintains insistence on a focindex of '1', is probably because it can't be '0' anyway...

I haven't used check boxes in a long time and forget how they interact with a stack, but they do sound like the proper control type for your business requirements.

This message has been edited. Last edited by: Dave Ayers,

John,

From a design/usability standpoint, I think a group of radio buttons should always have one button selected, whether it be by default or user selection.

Regards,
Dave

I sort of agree with David, a group of radio buttons should always have one button set to selected.
So what I do in these cases is to have one radio button more than actually needed, give it a value of 'none' or 'nothing' or something like that, and set the stack's focindex to that button. Then I hide this particular button by specifying either rows or columns to be one less then is actually in the stack. That way the radio buttons shown are always unselected, and leaving them that way will return the index of the last, invisible, radio button as being the selected one. In the maintain you can test this.

In this particular case the radio set is a pregnant-male scenario so its use is proper from a usability perspective. That said, regardless of the state of the radio buttons on the form (active or not) the state of them is reported incorrectly in Maintain. It appears I will need to code a separate integer variable in JavaScript behind the radio set (and one other whose state is also germane) that captures the value manually and then use that for my solution.

Thank you all. I was hoping I had just made a mistake in the code or overlooked a feature.

J.

John
I actually have a VERY easy way to do this. The trick is, create one more item on your Radio Group than you need. If you are hardcoding your entries add one to the bottom. If the values are coming from a stack add a value to the bottom of the stack. Then, set the FocIndex to that value. Either:
Compute Form.RadioGroup.ListItems.Focindex = n;
or Compute Radiostk.Focindex = RadioStk.Foccount

Finally, when you draw the Radio Group on the form, truncate the last line. You cannot scroll a Radio Group. It shows up with no selection. When you test for response, if the value is the last line, then nothing has been selected.

Yes, it is a work-around and it will not work if you do not know the number of values in the stack, but otherwise it is a good solution.

Mark

For those following along at home, be sure to add an item to the list for the radio buttons AND be sure to set the ListItems attribute to the correct number in the properties box on the right-hand side of the interface. If you overlook the second step the interface will not recognize the new item in your JavaScript.

J.

I see that people have come up with a workaround for the stack 'problem', but I wonder if it is the proper response to the User Interface problem.

While I'm not exactly sure what information is being captured by the form, I have a suspicion that Radio buttons are not the correct control for this situation.

Check out Jacob Nielsens article on Checkboxes vs. Radio Buttons at:

http://www.useit.com/alertbox/20040927.html

to determine the correct type of control for your interface.

And while you are there you might want to bookmark and browse for other UI guidelines !

I don't find that IBI's products, or code samples, are good examples of User interface design

Checkboxes provide a visual cue indicating a binary state of a single, independent concept. Grouping them indicates a thematic relationship to new users, but not dependent functionality. You can code whatever you want with them, but the very fact that they are not designed to work in conjunction with each other is a solid indication that the W3C never intended for them to do so.

Radio buttons provide two or more exclusive selections to choose from. The state I am capturing is indeed a set of exclusive states, that may or may not be pertinent to the instance of the data being entered. In the event the state is pertinent, a radio selection is warranted as only one option can be selected -- the default behavior of the control. In the event the state is not pertinent, no state, neither positive nor negative is applicable and therefore should not be captured or implied -- a "missing" value makes intuitive sense to the operator and is the proper information to store in the table. In that event, the control is cleared and deactivated, but maintains its position on the screen to provide a predictable interface to the enduser.

I did not mean to muddy the point with the generic phrase "pregnant male" where a single checkbox could make logical (though somewhat comical) sense. I would argue that in the case of a male gender that the "pregnant" checkbox should be disabled as well -- a state of "not applicable" is warranted under the circumstances. The actual subject matter of the radio buttons I am coding has a tendency to draw people off topic very quickly and I find it useful to leave that aspect out of the discussion on the forums for the obvious reason.

A good topic nonetheless. I took a peek at the page you referenced and Nielsen seems to largely be in agreement with me.

J.

John,

Since you have further defined the usage of your radio buttons:

<< The state I am capturing is indeed a set of exclusive states, that may or may not be pertinent to the instance of the data being entered.

The following, from Jakob Nielsen's Alertbox, applies:

"9. # Always offer a default selection for radio button lists. By definition, radio buttons always have exactly one option selected, and you therefore shouldn't display them without a default selection.

* If users might need to refrain from making a selection, you should provide a radio button for this choice, such as one labeled "None." Offering users an explicit, neutral option to click is better than requiring the implicit act of not selecting from the list, especially because doing the latter violates the rule of always having exactly one option chosen. "

Adding a 'Not Applicable', 'None', or whatever, radio button will satisfy the UI rule, be clearer for users, and give you a default stack row, eliminating the need for a workaround

Frankly, I think Nielson is just wrong, particularly in the light of Active HTML. You wanna make a user happy? Gray out the 42 fields that don't apply to them and move the cursor to the 43rd. Immediate understanding, reduction of work, associative integrity of inbound data.

"Requiring the implicit act of not selecting" is a pretty profound concept though. I have to give him some credit for that one.

"You'll get nothing and like it!" -- Judge Smails

J.