royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: MXMLDataInterpreter
Date Tue, 05 Dec 2017 19:08:34 GMT
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.


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
>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
>Any clues as to why this is and what will happen if I change this?

View raw message