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... > >> > >> > >
