I didn't see that in your 'text picture', but yes you are correct, the FocusManager does not handle that condition. You're welcome to try to fix it.
-Alex On 9/20/13 8:05 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote: >Absolutely, but if there are other controls "interleaved" with the radio >buttons of the same group, when the focus leave this interleaved >components >the focus is "moved back" to the selected button... even if this is >"before" in the computed tab loop, actually creating a closed tab loop >that >is impossible to escape without using the mouse. > > > > >2013/9/20 Alex Harui <aha...@adobe.com> > >> The default behavior on Windows is/was that you tab to a group of radio >> buttons which will focus the selected one or the first one if none are >> selected, then use arrow keys to move between them. Another tab moves >>you >> to the next/previous control or group. >> >> The Flex FocusManager attempts to replicate that behavior. Is that what >> you are seeing? >> >> -Alex >> >> On 9/20/13 7:08 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote: >> >> >Hi list, maybe I found an issue with keyobard focus manager. >> >I have a situation like this (hope you get the pic): >> > >> > >> >[previous controls] >> >[radio A] [radio B] >> > [radio A1] [radio B1] [text input] >> > [radio A2] [radio B2] >> >[next controls] >> > >> > >> >Now, the tab focus management is completely broken: >> > - when focus is on [radio A2], tab go back to [radio A] - there's no >>way >> >to move to [next controls] >> > - when focus is on [text input], tab go back to [radio B1] - again, no >> >way >> >to move to [next controls] >> > >> > >> >I think that the bug is in the FocusManager.getIndexOfNextObject >>method: >> >when focus is on [radio A2], the next focus candidate is [radio B] >>(due to >> >containers visual layout), but it is part of a focus group, so the >> >FocusManager bring it to *the selected element of its focus group*, >>that >> >is >> >[radio A]. >> > >> >In my opinion, this should be done only if no other elements of the >> >same focus group have an index, in the focus candidate list, that is >>less >> >then the index of the current focused component, to avoid "moving back" >> >the >> >focus and creating closed tab loops (maybe reversing the index check >>when >> >moving focus backwards). >> > >> > >> > >> >The only workaround I found so far is structuring the containers so >>that >> >component belonging to the same focus group are kept adjacent, but it >>is >> >very difficult (if not impossible) to achieve the same visual output >>(e.g. >> >put [radioA] and [radioB] in a dedicated HGroup, ditto for [radio B1] >>and >> >[radio B2], trying to keep [text input] aligned to [radio B1] someway). >> > >> >Any thoughts on this? If I'm not missing something obvious, I'd like to >> >file an issue... >> >>
