Opened the issue FLEX-33772 and attached a sample app and a patch. I've only been able to test it as a monkey patch in some sample apps and in the application where the problem was first noticed, I hope that someone could be able to review it.
Thanks! 2013/9/20 Alex Harui <aha...@adobe.com> > 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... > >> >> > >> >> > >> > >> > >
