The FocusManager doesn't want to know about internal focus targets, it really only wants to know about the "component". For example, in mx:TextInput, the internal focus target (stage.focus) is a TextField, but from the developer's and FocusManager's perspective, the focus is on the wrapping TextInput "component". When editing a DG, the DG has focus from the FocusManager's perspective, and the DG is calling preventDefault and moving focus to the editor control.
This "component" abstraction is managed via the focusEnabled property. Subcomponents must have focusEnabled=false, and only the outer component should have focusEnabled=true. It is only the outer component that should be in the list of candidates. Your multiple internal targets should not be known to the FocusManager. I think the "owner" code you cited is mainly for managing things like popups and dropdowns. In ColorPicker, the dropdown swatch panel can have focus and we need to use "owner" to walk back to the ColorPicker. So, my guess is that you haven't set the focusEnabled properties on your component tree properly. On 5/7/13 9:21 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote: > Thanks Alex. > > In my test I was never preventing it, but the tab focus movement to the > next component was not worked (I expected to always move forward, at > least): for some reason, the internal focus target was not part of the > FocusManager tab loop candidates. I saw that, in this case, the > FocusManager does a second pass on candidates and stops on the *first* > candidate "owning" the current focused element, which works with simple UIs > but often produce incorrect results (e.g. when the component is in an > Accordion). Maybe the FocusManager could at least use the *last* owning > candidate (thus narrowing the search towards the tree leaf), instead of the > first one? > > > > > 2013/5/7 Alex Harui <aha...@adobe.com> > >> That interface is, in fact, only for the initial assignment of focus to the >> component that wraps multiple targets. That wrapping component must then >> manage tab focus on its own by handling the keyFocusChange event and >> calling >> preventDefault on it when it wants to keep focus on one of the wrapped >> controls. >> >> HTH, >> -Alex >> >> >> On 5/7/13 8:33 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote: >> >>> Anyone know something about this interface ([1] on github)? >>> >>> Its asdoc states "the IFocusManagerComplexComponent interface defines the >>> interface that components that can have more than one internal focus >> target >>> should implement in order to receive focus from the FocusManager" - so I >>> tried to implement it this scenario, but it does not seem to work. >>> >>> In particular, the FocusManager implementation look for it when it must >>> give focus to a component (see [2]), however tab focus management seems >>> broken using it (I think that FocusManager should check if the current >>> focus is on a component that is an "internal focus target" of a complex >> one >>> when looking it up in the tab loop, to correctly determine the next focus >>> manager component). >>> >>> >>> [1] >>> >> https://github.com/apache/flex-sdk/blob/trunk/frameworks/projects/framework/s>> r >>> c/mx/managers/IFocusManagerComplexComponent.as >>> >>> [2] >>> >> https://github.com/apache/flex-sdk/blob/trunk/frameworks/projects/framework/s>> r >>> c/mx/managers/FocusManager.as#L1450 >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> >> -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
