You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2018/09/15 17:34:04 UTC

Ensuring other components are created so a List can dispatch a CHANGE event when selectedIndex is defined in MXML

Hi,

I'm fixing List selectedIndex when the user predefines a selectedIndex in
MXML.

The problem was that renderers are not still created when the list tries to
select the right item.

I'm listening to "itemsCreated" event, and all is working right :)

But...I have a side problem:

When the selectedItemChangeHandler runs it finally dispatch a CHANGE event.

This means the App code runs an event handler to assign the selectedItem
text to a Label.

The problem is the label is still not created at that time what throws an
error.

So, two questions here:

a) Is ok to dispatch the CHANGE event for a preselected index?

b) when I can ensure other components are created in Royale from a
component design point of view so I can dispatch the change event at proper
time.

Thanks



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Ensuring other components are created so a List can dispatch a CHANGE event when selectedIndex is defined in MXML

Posted by Carlos Rovira <ca...@apache.org>.
Ok Alex, that was a doubt I have.
I commit a change to avoid List dispatch CHANGE when user set selectedIndex
I think is ok since it doesn't loop just through data, just check if
selectedIndex is  > -1 and runs selectedIndexHandler to set the renderer.
This is done by getItemRendererAt that get the renderer what does a
UIBase.getItemAt that finally does a children[[index].royale_wrapper
So the renderers are created by the factory. then a itemsCreated event is
dispatched and the view respond selecting the renderer and avoids to
dispatch CHANGE event.


El dom., 16 sept. 2018 a las 4:28, Alex Harui (<ah...@adobe.com.invalid>)
escribió:

> Hi.
>
> In theory, setting selectedIndex on a List should only change the model
> and not fire a CHANGE event.  Almost all events like CLICK and CHANGE are
> interaction notification events.  IOW, that the user changed something.  If
> the application code changes something, there usually isn't an event.
> Pretty sure that's how it worked in Flex.
>
> Then, when the View is added to the strand, it should find that
> selectedIndex is set in the model.  However, I would think a ListView
> wouldn't have much to do.  The ItemRenderer Factory should create renderers
> and intialize their "state" to indicate selected.  That should be more
> efficient than looping through renderers to set one of them.
>
> HTH,
> -Alex
>
> On 9/15/18, 10:34 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
>     Hi,
>
>     I'm fixing List selectedIndex when the user predefines a selectedIndex
> in
>     MXML.
>
>     The problem was that renderers are not still created when the list
> tries to
>     select the right item.
>
>     I'm listening to "itemsCreated" event, and all is working right :)
>
>     But...I have a side problem:
>
>     When the selectedItemChangeHandler runs it finally dispatch a CHANGE
> event.
>
>     This means the App code runs an event handler to assign the
> selectedItem
>     text to a Label.
>
>     The problem is the label is still not created at that time what throws
> an
>     error.
>
>     So, two questions here:
>
>     a) Is ok to dispatch the CHANGE event for a preselected index?
>
>     b) when I can ensure other components are created in Royale from a
>     component design point of view so I can dispatch the change event at
> proper
>     time.
>
>     Thanks
>
>
>
>     --
>     Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cf6e27b206aee4eb6b71108d61b317810%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726296643855320&amp;sdata=rDLvpocaULjYUWjLcFYACTGy%2Blub2Vg2MRgESTj3sNU%3D&amp;reserved=0
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Ensuring other components are created so a List can dispatch a CHANGE event when selectedIndex is defined in MXML

Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi.

In theory, setting selectedIndex on a List should only change the model and not fire a CHANGE event.  Almost all events like CLICK and CHANGE are interaction notification events.  IOW, that the user changed something.  If the application code changes something, there usually isn't an event.  Pretty sure that's how it worked in Flex.

Then, when the View is added to the strand, it should find that selectedIndex is set in the model.  However, I would think a ListView wouldn't have much to do.  The ItemRenderer Factory should create renderers and intialize their "state" to indicate selected.  That should be more efficient than looping through renderers to set one of them.

HTH,
-Alex

On 9/15/18, 10:34 AM, "Carlos Rovira" <ca...@apache.org> wrote:

    Hi,
    
    I'm fixing List selectedIndex when the user predefines a selectedIndex in
    MXML.
    
    The problem was that renderers are not still created when the list tries to
    select the right item.
    
    I'm listening to "itemsCreated" event, and all is working right :)
    
    But...I have a side problem:
    
    When the selectedItemChangeHandler runs it finally dispatch a CHANGE event.
    
    This means the App code runs an event handler to assign the selectedItem
    text to a Label.
    
    The problem is the label is still not created at that time what throws an
    error.
    
    So, two questions here:
    
    a) Is ok to dispatch the CHANGE event for a preselected index?
    
    b) when I can ensure other components are created in Royale from a
    component design point of view so I can dispatch the change event at proper
    time.
    
    Thanks
    
    
    
    -- 
    Carlos Rovira
    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cf6e27b206aee4eb6b71108d61b317810%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726296643855320&amp;sdata=rDLvpocaULjYUWjLcFYACTGy%2Blub2Vg2MRgESTj3sNU%3D&amp;reserved=0