royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
Subject Re: MXMLDataInterpreter
Date Tue, 05 Dec 2017 22:13:34 GMT
Thanks. This is exactly the info I needed.

A few points:

1. I think it’s useful for dispatch a ValueEvent with the element added as the payload.
For my bead, I need to add an event listener to each of the children.
2. For some reason addElement is only being overriden in GroupBase and ContainerBase for SWF.
It’s not dispatching the events for JS.
3 There is no even being dispatched for removeElement. If I’m attaching event listeners
when they are added, I should be removing those listeners when they are removed.
4. Assuming #1 makes sense, it feels like there should be two separate events: One for single
elements, and a second when all of them are added. It might make sense to keep childrenAdded
for en mass (with no payload), and elementAdded when a single element is added and dispatch
a valueEvent.

Some background on the bead I’m working on:
I’m trying to create a ToggleButtonBar. The idea is to allow a container to accept ISelectable
components which have a selected property and a bead will ensure that only a single ISelectable
is selected at any one time. It’ll also keep track of the selected index. The only way I
was able to figure out how to keep this generic and track the selected states of the components
was to attach change listeners to each of them.

> On Dec 5, 2017, at 9:08 PM, Alex Harui <> wrote:
> The 'dispatchEvent' parameter is not used in UIBase, because, in theory,
> at the low-level of simple controls, nobody needs to know if children are
> being added or removed dynamically.  The control author's code knows when
> it is going to add and remove elements and can update the rest of the
> control then.
> Because we don't really support method overloading, we chose to add a
> 'dispatchEvent' parameter so that it could be overridden in ContainerBase
> and control whether an event is dispatched as a child element is added.
> At MXMLDataInterpreter time, the belief is that it will never make sense
> to run the kinds of code associated with child adding as an MXML component
> springs to life.  So further down in MXMLDataInterpreter is a call to
> IContainer's childrenAdded() that signifies that all children specified in
> MXML have been added and now would be a good time to run layout and other
> things affected by child adding.
> I see that ContainerBase dispatches a childrenAdded event.  If you want to
> rename that to elementAdded, that's fine with me.
> HTH,
> -Alex
> On 12/5/17, 10:35 AM, "Harbs" <> wrote:
>> MXMLDataInterpreter has the following code:
>>           if (parent && comp is IChild)
>>               parent.addElement(comp as IChild, !(parent is
>> IContainer));
>> The boolean second value is the “dispatchEvent” parameter in the method.
>> Currently, dispatchEvent does nothing (i.e. no event is dispatched in
>> either case), but I am working on a bead which needs to listen for
>> element added events. To wit, I added an “elementAdded” event which is
>> dispatched when dispatchEvent is true.
>> I need the bead to be notified when elements are added via MXML in
>> addition to AS code, but addElement is being called with dispatchEvent as
>> false.
>> Any clues as to why this is and what will happen if I change this?
>> Harbs

View raw message