wiln / flexlib

Automatically exported from code.google.com/p/flexlib
0 stars 0 forks source link

PromptingTextInput updates the _textEmpty only after binding occurs. #139

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create a two text inputs like this (source and "mirror"):
    <controls:PromptingTextInput id="text" prompt="Hello there" />
    <mx:TextInput text="{text.text}" />
2. Run the application and type one letter into the PromptingTextInput
3.

What is the expected output? What do you see instead?
The TextInput value should be the letter you type into the PromptingTextInput.

Instead, the mirror TextInput remains empty.
If you type another letter the mirror text will get the correct value.

What version of the product are you using? On what operating system?
Flex 3, flexlib revision 157.

Please provide any additional information below.

This bug occurs because when the change event is dispatched from the
prompting text, the _textEmpty value is still true.
only later, it's updated.
This is because the binding event priority is 100 EventPriority.BINDING,
where as the PromptingTextInput.handleChange is registered with the default
event priority (0).

To solve this, I changed the event registration by setting the priority to
EventPriority.BINDING, this promises that the handleChange is called first.

    public function PromptingTextInput()
    {
        _textEmpty = true;

        addEventListener( Event.CHANGE, handleChange, false, EventPriority.BINDING );
        addEventListener( FocusEvent.FOCUS_IN, handleFocusIn );
        addEventListener( FocusEvent.FOCUS_OUT, handleFocusOut );
    }

Original issue reported on code.google.com by akurt...@gmail.com on 8 Jul 2008 at 11:17

GoogleCodeExporter commented 8 years ago
I can confirm this fixes the bug in question. In my case, I was experiencing 
weird
symptoms where data binding wouldn't work until the second character was 
entered.

I've attached a diff that applies cleanly to current trunk svn to fix it.

Original comment by paul...@gmail.com on 18 Jul 2008 at 9:29

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I was having a problem with binding to the text.  Text length was 0 until more 
than one character was typed.  
Fixed it be opening up the source and replaces get text with 

override public function get text():String
    {   
        // If the text has changed      
        if( super.text == _prompt )
        {
            // Skip the prompt text value
            return "";
        }
        else
        {
            return super.text;
        }       
    }

Original comment by cha...@gmail.com on 12 Sep 2008 at 12:07

GoogleCodeExporter commented 8 years ago
Did you try to apply the patch?
the EventPriority.BINDING (=100) is suppose to fix it.

Original comment by akurt...@gmail.com on 12 Sep 2008 at 12:16

GoogleCodeExporter commented 8 years ago

Original comment by dmcc...@gmail.com on 8 Jan 2009 at 5:21

GoogleCodeExporter commented 8 years ago

Original comment by olarivain@gmail.com on 29 Mar 2010 at 1:27

GoogleCodeExporter commented 8 years ago
Issue 192 has been merged into this issue.

Original comment by olarivain@gmail.com on 29 Mar 2010 at 1:29

GoogleCodeExporter commented 8 years ago
I've had similar issues with this component :
1. binding problems as described above (and much)
2. flickering when changing the displayAsPassword property (a show password 
feature)
3. htmlText holds the prompt value when the component is created (instead of 
being empty)

I've looked at the class and there are things that are written in the part of 
the component life cycle they don't belong (updateDisplayList).

I've attached a fix and a flex builder project to compare the two solutions. I 
only tested with the latest Flex 3 sdk. It is more consistent and more binding 
friendly.

Original comment by switcher...@gmail.com on 8 Mar 2011 at 7:19

Attachments:

GoogleCodeExporter commented 8 years ago
And I forgot to mention that the prompt and promptFormat properties are 
currently not null-safe (which I also fixed).

Original comment by switcher...@gmail.com on 8 Mar 2011 at 7:25