Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

New TIBCO Community Coming Soon
In early summer, TIBCO plans to launch a new community—with a new user experience, enhanced search, and expanded capabilities for member engagement with answers and discussions! In advance of that, the current myibi community will be retired on April 30. We will continue to provide updates here on both the retirement of myibi and the new community launch.

What You Need to Know about Our New Community
We value the wealth of knowledge and engagement shared by community members and hope the new community will continue cultivating networking, knowledge sharing, and discussion.

During the transition period, from April 20th until the new community is launched this summer, myibi users should access the TIBCO WebFOCUS page to engage.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [Pretty Much Solved] WF Maintain -- Capturing that a Radio Group has nothing selected

Read-Only Read-Only Topic
Go
Search
Notify
Tools
[Pretty Much Solved] WF Maintain -- Capturing that a Radio Group has nothing selected
 Login/Join
 
Virtuoso
posted
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,



 
Posts: 1012 | Location: At the Mast | Registered: May 17, 2007Report This Post
Platinum Member
posted Hide Post
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,


Regards,
Dave

http://www.daveayers.com

WebFocus/Maintain 7.6.4-8
on Win2000 and 2003 Server
 
Posts: 165 | Location: Detroit Metro | Registered: September 17, 2003Report This Post
Master
posted Hide Post
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




Pilot: WebFOCUS 8.2.06 Test: WebFOCUS 8.1.05M Prod: WebFOCUS 8.1.05M Server: Windows Server 2016/Tomcat Standalone Workstation: Windows 10/IE11+Edge Database: Oracle 12c, Netezza, & MS SQL Server 2019 Output: AHTML/XLSX/HTML/PDF/JSCHART Tools: WFDS, Repository Content, BI Portal Designer & ReportCaster
 
Posts: 822 | Registered: April 23, 2003Report This Post
Virtuoso
posted Hide Post
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.


GamP

- Using AS 8.2.01 on Windows 10 - IE11.
in Focus since 1988
 
Posts: 1961 | Location: Netherlands | Registered: September 25, 2007Report This Post
Virtuoso
posted Hide Post
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.



 
Posts: 1012 | Location: At the Mast | Registered: May 17, 2007Report This Post
Master
posted Hide Post
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
 
Posts: 663 | Location: New York | Registered: May 08, 2003Report This Post
Virtuoso
posted Hide Post
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.



 
Posts: 1012 | Location: At the Mast | Registered: May 17, 2007Report This Post
Platinum Member
posted Hide Post
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 Frowner


Regards,
Dave

http://www.daveayers.com

WebFocus/Maintain 7.6.4-8
on Win2000 and 2003 Server
 
Posts: 165 | Location: Detroit Metro | Registered: September 17, 2003Report This Post
Virtuoso
posted Hide Post
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.



 
Posts: 1012 | Location: At the Mast | Registered: May 17, 2007Report This Post
Platinum Member
posted Hide Post
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 Smiler


Regards,
Dave

http://www.daveayers.com

WebFocus/Maintain 7.6.4-8
on Win2000 and 2003 Server
 
Posts: 165 | Location: Detroit Metro | Registered: September 17, 2003Report This Post
Virtuoso
posted Hide Post
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.



 
Posts: 1012 | Location: At the Mast | Registered: May 17, 2007Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [Pretty Much Solved] WF Maintain -- Capturing that a Radio Group has nothing selected

Copyright © 1996-2020 Information Builders