You can follow the monkey patching method for trying out new versions of FocusManager.
FWIW, I think the last time someone had this problem, I suggested that they use a Checkbox instead of RadioButton and use the RadioButtonSkin on the Checkbox. Then have their own logic that unselects the other checkboxes. That might be less work for you than trying to upgrade FocusManager. -Alex On 9/20/13 8:33 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote: >I like "text pictures" :) but here is a snippet: >http://pastebin.com/sYeHQKFQ >I'd like to attemp a fix, must find the time to setup my environment >(cannot rebuild the whole framework for each try). > > > >2013/9/20 Alex Harui <aha...@adobe.com> > >> 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... >> >> >> >> >> >>
