jump to navigation

Problems moving within a radio group May 12, 2008

Posted by Hob in erp, Flex, RIA, Uncategorized, workday.

I’ve recently been trying to add better keyboard control to some of our components.  One such component is basically a container with a set of radio buttons.  The radio buttons not only have labels, but also associated fields (TextInputs, ComboBoxes, etc.) that are only applicable when the radio button next to it is selected.  Thus, the radio button and its associated field both get wrapped in a container for alignment.

This particular component also supports the inclusion of a “None of the above” radio button.  For that particular item in the radio button list we were using a standard Flex RadioButton as there needs to be no associated field next to it.  The result of one of these instances might have a structure similar to this:

<mx:RadioButton label="None of the above"/>

The problem I ran into was this: My focus being set on any of the radio buttons in the list, I would start hitting the up arrow.  Once the arrow took me to the radio button physically at the top of the list, it would allow me to move one further, and take me back to the “None of the above” radio button.  For some reason it thought that “None of the above” was first in the list.

I started digging around and here’s what I found:  When RadioButtons are assigned a RadioButtonGroup (via their group property), they register themselves with that RadioButtonGroup via  call to the addInstance() method.  The problem is that the registration does not happen as soon as the group is added.  There are actually several possible places where it can happen, including commitProperties() and updateDisplayList().

This means that the order in which RadioButtons are added to their groups’ array of radio buttons is dependent on the flow of the component lifecycle.  The reason “None of the above” was at the top of the groups movement list was because it was the only one in the list of radio buttons that wasn’t also wrapped in another container.  The extra level of nesting for all the other radio buttons meant that they would get their updateDisplayList and commitProperties methods called after the “None of the above” button’s.

I wound up resolving the problem by wrapping the last radio button in the same type of container as all the rest.  Hopefully this helps someone else avoid having to spend a bunch of time on the same problem.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: