Interesting. We could do that, but it bugs me a bit. The deferred childrenAdded call is intended to close a transaction where addElement calls were told not to dispatch events on each call. If you look at it that way, a deferred childrenAdded call is an optimization option also available to folks just writing code in AS.
If we make it a required transaction for the creation of a Container then in AS it means that everybody has to remember to make that call. I’d like to avoid that requirement if possible. If you check out the layout wiki page [1], views like ContainerView should be checking 3 different scenarios. For an empty container, if sized by the parent, ContainerView should get an event and then run its view code which should call the layout code (which would do nothing as there are no children) then call the background bead. I’m guessing the background bead may not pick up the right size since nobody has set the size of the actualParent. If so, ContainerView should be setting the size. For a container sized to content, I would argue nothing should show up, or maybe the size needs to factor in padding. We’d have to see what browsers do. For a container with set dimensions, the ContainerView should be setting the actualParent’s size and background bead should be drawing accordingly. So maybe the bug is in there some where. Of course, I could be wrong… -Alex [1] https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout On 5/19/15, 7:27 AM, "Peter Ent" <p...@adobe.com> wrote: >I¹ve been looking into this. > >In MXMLDataInterpreter.generateMXMLInstances, if the data parameter is >null, the function immediately returns. This means you have something like ><js:Container /> - it has no children. > >I¹m wondering if a better approach might be to re-write this function as: > >public static function generateMXMLInstances(document:Object, >parent:IParent, data:Array):void >{ > if (data) generateMXMLArray(document, parent, data); > > // maybe we can remove this. All IContainers should be >IMXMLDocuments? > if (parent is IContainer) > { > IContainer(parent).childrenAdded(); > } >} > > >This way, childrenAdded is called all the time. It would mean that >zero-or-more children were added vs one-or-more children were added. This >would allow things that draw backgrounds to be called in a natural way. It >would also mean that code that is optimized to work for one-or-more >children should first check to see that there are children before >proceeding. > >That do you think? > >‹peter > >On 5/18/15, 5:11 PM, "Alex Harui" <aha...@adobe.com> wrote: > >> >> >>On 5/18/15, 1:51 PM, "Peter Ent" <p...@adobe.com> wrote: >> >>>The container appears to have no size. I have it explict (400x400) and >>>so >>>it should be a colored rectangle. Without content you get a blank >>>screen. >>>Add a label and you get the label inside a 400x400 colored box. >> >>Ah, ok. If the container does have size then yes, it should draw >>something. >>-Alex >> >
