Bump?
2013/9/23 Cosma Colanicchia <cosma...@gmail.com> > 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... >> >> >> >> >> >> >> >> >> >> >> >> >
