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