TextInput can't be made programmatically editable while it already has focus

[Cosma Colanicchia <co...@gmail.com>]

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

Re: TextInput can't be made programmatically editable while it already has focus

[Cosma Colanicchia <co...@gmail.com>]

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 <co...@gmail.com>

> 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 <ah...@adobe.com>
>
>> What is stage.focus?  Maybe just assign it to the RichEditableText.
>>
>> On 9/19/13 9:40 AM, "Cosma Colanicchia" <co...@gmail.com> 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 <ah...@adobe.com>
>> >
>> >> 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" <co...@gmail.com> 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
>> >>
>> >>
>>
>>
>

Re: TextInput can't be made programmatically editable while it already has focus

[Cosma Colanicchia <co...@gmail.com>]

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 <ah...@adobe.com>

> What is stage.focus?  Maybe just assign it to the RichEditableText.
>
> On 9/19/13 9:40 AM, "Cosma Colanicchia" <co...@gmail.com> 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 <ah...@adobe.com>
> >
> >> 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" <co...@gmail.com> 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
> >>
> >>
>
>

Re: TextInput can't be made programmatically editable while it already has focus

[Alex Harui <ah...@adobe.com>]

What is stage.focus?  Maybe just assign it to the RichEditableText.

On 9/19/13 9:40 AM, "Cosma Colanicchia" <co...@gmail.com> 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 <ah...@adobe.com>
>
>> 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" <co...@gmail.com> 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
>>
>>

Re: TextInput can't be made programmatically editable while it already has focus

[Cosma Colanicchia <co...@gmail.com>]

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 <ah...@adobe.com>

> 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" <co...@gmail.com> 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
>
>

Re: TextInput can't be made programmatically editable while it already has focus

[Alex Harui <ah...@adobe.com>]

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" <co...@gmail.com> 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