Filed issue FLEX-33773
2013/9/20 Alex Harui <[email protected]> > Yeah, please file a bug. > > > > > Sent via the PANTECH Discover, an AT&T 4G LTE smartphone. > > Cosma Colanicchia <[email protected]> wrote: > > > Checked with a 100ms timeout after the skinState change, focus is correctly > on the RichEditableText instance. I think the problem is that the > TLF container manager of RichEditableText is not correctly updating. > > Here is a simple snippet reproducing the problem with a plain TextInput > component. > > http://pastebin.com/md7TQEY5 > > > Should I file a JIRA issue for this? > > > > 2013/9/19 Alex Harui <[email protected]> > > > What is stage.focus? Maybe just assign it to the RichEditableText. > > > > On 9/19/13 9:40 AM, "Cosma Colanicchia" <[email protected]> wrote: > > > > >Thank you Alex, but unfortunately the text input has to be focusable > > >because it is part of a complex search component: it accept a query text > > >and, on return, display a popup list of results, once selected the text > > >input become not editable and display the selected item. In other words, > > >the user move focus to the non editable text field, hit DELETE button to > > >clear the current value, and starts typing to search for another value. > > > > > >In a previous approach I was using different skin parts for the display > of > > >the selected value and for entering the query text, but this was leading > > >to > > >other focus problem when the skinState of the component was switching > > >between the two (needed to "refocus" with mouse after clear/selection > via > > >keyboard shortcuts). > > > > > >With the current approach the component works perfectly, except when it > is > > >initially loaded with a value already set... I was hoping to find a way > to > > >trick it into initializing as an editable field in advance, to gain full > > >keyboard operativity. > > > > > > > > > > > >2013/9/19 Alex Harui <[email protected]> > > > > > >> Might be best to not allow focus if the control is not editable. Set > > >> tabEnabled and/or focusEnabled=false. > > >> > > >> On 9/19/13 2:45 AM, "Cosma Colanicchia" <[email protected]> wrote: > > >> > > >> >Hi, I have a little issue with the default TextInput component, could > > >>not > > >> >find it in already logged issues - at least I think so, there are a > > >>lot of > > >> >issues about text input components. > > >> > > > >> >This is the scenario: > > >> > > > >> >1) the component instance start with editable="false" > > >> >2) user moves focus to component using the keyboard > > >> >3) a particular key press activates editability of the field > (through a > > >> >custom keyDown listener) > > >> >4) no cursor displayed, can't type in the field > > >> > > > >> >Notes: > > >> > - this is happening with the default (TLF-based) TextInput skin > > >> > - moving away focus and getting back to it (with keyboard or mouse, > or > > >> >even with an ALT-TAB) cause the component to start behaving correctly > > >> > - if the instance has been previously editable, the behavior doesn't > > >> >reproduce > > >> > - if the focus is moved to the component through a mouse click the > > >>issue > > >> >is not triggered > > >> > > > >> > > > >> >As a workaround, I tried a callLater(textInput.setFocus) on my custom > > >> >keyDown listener, without success. Replacing the callLater with a > > >> >setTimeout also doesn't work (in both cases, it seems that its > > >>setFocus() > > >> >override of RichEditableText does nothing because the check on the > > >>compose > > >> >state of the text container manager. > > >> > > > >> >Any hint? > > >> >TIA > > >> > > >> > > > > >
