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" <[email protected]> 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
