To try it out: 1) launch the app 2) keyboard tab to the text input 3) hit delete on keyboard 4) see that you can't type 5) tab again to move on button, hit spacebar to click 6) tab back to the text input 7) hit delete on keyboard 8) now it works correctly
And, alternative version 1) launch the app 2) click with mouse on the text input to focus it 3) hit delete on keyboard 4) you can type correctly You can verify using the bottom label that the stage focus is always on the RichEditableText... I'm trying with the latest develop branch SDK (rebuilt it two days ago). 2013/9/20 Cosma Colanicchia <[email protected]> > 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 >> >> >> >> >> >> >
