Easy thing first: The bubbling of layoutNeeded from Image is a hack and should
go away someday.
Turns out I was wrong and JS LayoutBase is not listening for
widthChanged/heightChanged/sizeChanged. That was SWF-only code I saw earlier.
IMO, that's the first thing to change by overriding handleChildrenAdded in
BoxLayout and other MX Layouts. I don't think Basic layouts need to watch
children for size changes.
Also UIComponent's setActualSize() should set the noEvent flag on
setWidthAndHeight.
The reason I'm suggesting these changes is because I think that's closer to
what Flex does. I don't think Flex has logic like
sizeChangedBeforeLayout/sizeChangedDuringLayout logic.
For some reason, ApplicationLayout is not getting the handleChildrenAdded. I
will work on it more tomorrow.
HTH,
-Alex
On 6/6/20, 12:16 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
Long day... I stepped away from the keyboard and thought I had finished
that when I returned.
But this: ' although I know it's not a ' needs ''one:one mapping for
features/behavior" on the end (or something like that!)
On Sat, Jun 6, 2020 at 7:13 PM Greg Dove <greg.d...@gmail.com> wrote:
>
> Yeah, that is the sort of thinking that I was trying to make work with
> what is there already (and yes it does seem like maybe something else is
> missing). Apart from simple size changes, it is the change on measuredSize
> after layout has happened in the child that I think some parents *might*
be
> interested in when their children are containers with percent dimensions
> ('flexible' children I think is how they are described in some Flex code -
> this sort of makes me think of css Flexbox a bit when I look at what the
> BoxLayout stuff is doing, although I know it's not a ).
> But I am probably only scratching the surface here, you have the
> experience with this stuff.
> In terms of plumbing, one thing I pondered about would be whether MXRoyale
> layouts could form their own tree where they connect/detach directly to
> eachother as part of addChild/removeChild so that it is almost like a tree
> in parallel with the display tree.
> Maybe that could be a structure where they talk to each other directly up
> and down the tree with measurement and layout order somehow optimized. I
> think it still would not be as efficient as using the 'temporal buffer' of
> the Flex life cycle, with enterFrame or with 'requestAnimationFrame' but
> maybe it could be a little better... not sure, was just a thought and I
> know it seems like a radical change, so maybe that alone rules it out.
>
> I was going to drop another zip into the github issue. It occurred to me
> that it might be easier for you to test if I just put the changed files
> into the test app fileset as a monkey patch. That way you can mess with
> them locally more easily if you want to make quick changes and retest,
> without recompiling MXRoyale. (I was doing this a bit with
GridItem/GridRow
> today in the app I am working on, where I have the monkey patch approach
> and it's quite a bit faster when testing changes).
>
> A little aside: one other thing I think I noticed today... I think mx
> Image has a 'layoutNeeded' dispatch on image load. That makes sense. But I
> think I saw that it is a bubbling event. Is that correct? Would this call
> layoutNeeded all the way up to SystemManager for a deeply nested Image (I
> did not check if it does yet)?
>
> Thanks again for looking at this. If I can help by creating more test
> cases or looking into anything specific in more detail, let me know.
> Greg
>
>
>
>
>
>
>
> On Sat, Jun 6, 2020 at 6:30 PM Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
>> I hope to have time tomorrow.
>>
>> Looking quickly at the things you've tried to fix the problem, it occurs
>> to me that the piece that is probably missing in MXRoyale is the
>> propagation of something like invalidateSize() instead of just
>> "layoutNeeded". My thinking is that in the general case the child can't
>> really know that because something about the child changed that the
parent
>> needs to run a new layout and especially the parent of that parent.
>>
>> So some new plumbing may be needed where, when a component changes in a
>> way that its measured or explicit size had changed (as opposed to the
size
>> change from the parent laying out the child), that some sort of
>> layoutMightBeNeeded is sent to the parent which then uses its measurement
>> code and explicit sizes to determine whether its size has changed and
>> propagates a layoutMightBeNeeded to its parent. But if it decides its
size
>> has not changed, it would then run layout which should start the parents
>> laying out children.
>>
>> We'll see if the test case points in that direction.
>>
>> HTH,
>> -Alex
>>
>> On 6/5/20, 3:05 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>
>> Hi Alex, thanks for the detailed explanation and offer to take a
>> look, for
>> now some quick replies inline.... please add questions in the github
>> issue
>> if you want more details about anything I did so far.
>> thanks
>> Greg
>>
>> On Fri, Jun 5, 2020 at 6:50 PM Alex Harui <aha...@adobe.com.invalid>
>> wrote:
>>
>> > Greg,
>> >
>> > I think this thread got forked somehow. If you have a simple test
>> case I
>> > can try to look at it this weekend.
>> >
>> > Thanks. I added issue #849 [1] which should give you something to
>> look at.
>> I suggest you open the Flex build in a browser and then compare
>> things to
>> it in Royale. There are 2 royale builds as well with the same code in
>> the
>> other 2 zips. One without the modifications to MXRoyale and one with.
>> The
>> 'one with' zip also has the modified MXRoyale files, so you should be
>> able
>> to drop them in and overwrite in your local MXRoyale and build to
>> test/review/change what I did. I'm the first to admit that I do think
>> it
>> doesn't feel right. But so far at least it does make a bunch of code
>> work
>> in one app with a lot of deeply nested layouts that was not working
>> before.
>> It certainly does not make everything work. But it helps quite a bit.
>> Certainly appreciate any review/consideration. I am really keen to
>> collaborate on a solution that makes sense for most here.
>>
>> I don't doubt that the changes you propose work for you, but they
>> make me
>> > nervous although I'm not the best at reading code and understanding
>> what it
>> > does. Here's a brain dump on layout in case it helps.
>> >
>> > So far they work better 'for me' I agree. But I think you probably
>> know me
>> enough by now to know that if I am confident that I have a
>> contribution
>> that is objectively good (passes unit tests compared with swf is my
>> normal
>> benchmark) then I will add it. Part of the reason I started this
>> discussion
>> is because I feel a bit the same way here. I am still learning this
>> stuff
>> and figuring things out, so I am not pushing it because I don't want
>> to
>> inflict anything that is not an objective improvement on others.
>>
>> In terms of describing it, the main thing I think, is that the view
>> checks
>> when layout happens if there was a size change since last time layout
>> ran,
>> or if there was a change in size during the current run. Then there
>> is some
>> somewhat awkward checking to see if the parent might be interested in
>> this
>> because there is some 'sizedToContent' aspect to it (which includes a
>> percentage variation on that check). If we think it is relevant, then
>> request the parent to layout. Is this likely to do it sometimes when
>> it is
>> not needed, I suspect so. But so far it has not caused any problems
>> in the
>> codebase I am working with.
>>
>> I'm also working on the Grid related stuff, but you could probably
>> just
>> ignore that for now and focus only on the BoxLayout stuff.
>>
>> In Flex, parents always size their children. The children probably
>> > shouldn't override that size or if they do they have to be careful
>> that it
>> > doesn't trigger the another layout in the parent in a way that you
>> run
>> > layout forever (a "layout loop"). In Flex, because of the
>> LayoutManager
>> > running on frame events, that generally doesn't freeze the UI and I
>> have
>> > seen situations where the LayoutManager never goes idle even though
>> the app
>> > appears to be running fine. There is also the case where the first
>> layout
>> > pass results in scrollbars which causes children to adjust and
>> results in
>> > the removal of scrollbars and that loops forever with the
scrollbars
>> > blinking on and off. In Royale, there is a greater chance of
>> hanging.
>> >
>> > Also in Flex, with the LayoutManager, EVERY widget added itself to
>> the
>> > LayoutManager ensuring validation in a particular order, enforcing
>> the
>> > "parents size children" rule.
>> >
>> > In Royale, I tried to go without a LayoutManager because we started
>> out
>> > targeting IE8 and I wasn’t sure if there were some things that were
>> > exceptions to requestAnimationFrame (like setting text or sizing
>> images).
>> > To this day, I'm concerned that it will create an poor debugging
>> experience
>> > because I think when you hit breakpoints the screen updates. All
>> of those
>> > things need testing before we try a LayoutManager based on
>> > requestAnimationFrame. And then, as I think you mentioned, we have
>> to be
>> > concerned about how much code is going to run if we start running
>> all of
>> > the validation methods.
>> >
>> > On the other hand, I think Royale runs layout too often still
>> because two
>> > property changes can trigger two layout passes. I looked at
>> BoxLayout
>> > which extends LayoutBase which does already watch for
>> > widthChanged/heightChanged/sizeChanged so whatever is the root
>> cause of
>> > your problem may not be triggering the layout pass you want,
>> although the
>> > code paths in LayoutBase.childResizeHandler are there to prevent
>> layout
>> > loops.
>> >
>> > Usually, in Flex, a component didn't change its size in response to
>> user
>> > interaction or data loading, it changed its measured size and
called
>> > invalidateSize on itself and its parent. The LayoutManager
measured
>> > children before parents, then layed out parents before children.
>> >
>> > Yeah, that's the vague notion I had, your explanation has helped
>> cement my
>> understanding.
>>
>>
>> > In Royale, there is little to no measurement subsystem. That's
>> because we
>> > rely on the browser to "immediately" measure by setting
>> > offsetWidth/offsetHeight saving us the impossible task of writing
>> code to
>> > guess at how the browser measures. For PAYG reasons in Basic,
>> there is no
>> > code looking for changes that should trigger a layout other than
>> possibly
>> > child size changes. Everything else is supposed to use
>> > LayoutChangeNotifier to wire the one event that signals a change to
>> the
>> > container/layout that cares.
>>
>> In MXRoyale, there are complex components that can't rely on
>> > offsetWidth/Height since MXRoyale cannot rely on browser layout
>> because of
>> > things like overriding the meaning of width=100%. MXRoyale has
>> measure()
>> > methods from Flex, but they don't always get run because there is
no
>> > LayoutManager measuring the children before the parents and
existing
>> > measure() methods expect the children to have been measured. It
>> might be
>> > that is the root cause here. That some or all invalidateSize()
>> calls need
>> > to call measure() and then instead of calling layoutNeeded on the
>> parent,
>> > call the parent's invalidateSize until somehow we know we've gone
>> far
>> > enough up the chain to start laying out again.
>> >
>> > After the changes I made I do still need to make changes in some
>> specific
>> areas, but usually this type of thing does the trick:
>>
>> var layout:BoxLayout =
>> containerContents.getBeadByType(BoxLayout) as BoxLayout;
>> if (layout) {
>> layout.measure();
>> }
>> containerContents.layoutNeeded();
>>
>> Note: calling measure() explicitly like that with BoxLayout seems to
>> be
>> necessary sometimes before an explicit layout request. It might only
>> work
>> more after the changes I made, not sure whether it makes a difference
>> before or not.
>>
>>
>> > HTH,
>> > -Alex
>> >
>> >
>> > On 6/4/20, 1:51 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>> >
>> > 'I don’t think we’ve dealt with a lot of children changing
>> sizes (other
>> > than Images loading late and a few other things) so it may be
>> time to
>> > listen to widthChanged/heightChanged/sizeChanged as children
>> get added
>> > if
>> > there isn’t already code doing that.'
>> >
>> > That would be another way of doing it. There is already this
>> code [1]
>> > that
>> > is swf-only but seems to only be relevant before
>> sawInitComplete.
>> >
>> > But if the children run their layouts when their own size
>> changes, then
>> > they can notify their parent as well if the size changed either
>> before
>> > or
>> > during layout. That's sort of what I was trying to do with the
>> > ContainerView change I mentioned earlier. It checks size for
>> change in
>> > beforeLayout and again in afterLayout and then requests parent
>> layout
>> > if it
>> > thinks the parent needs to do something that could affect
parent
>> > layout or
>> > even re-apply its own rules to the current target. In this way
>> there
>> > is not
>> > a need to add listeners to every child. But I expect there are
>> some
>> > downsides or things I cannot see with what I did so far because
>> I have
>> > not
>> > spent a lot of time in this code, as you have. I'll post more
>> details
>> > in
>> > the github issue at my EOD.
>> >
>> > 1.
>> >
>> >
>>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F9c70b052a6fef3ebe7c6a07ca887af4f7381d46f%2Fframeworks%2Fprojects%2FCore%2Fsrc%2Fmain%2Froyale%2Forg%2Fapache%2Froyale%2Fcore%2FLayoutBase.as%23L131&data=02%7C01%7Caharui%40adobe.com%7C8a6459c6e39047dd9d4608d809e97d92%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637270245738238954&sdata=DtytJwdH1LB91GBcUzPsMGrDRL2jIHAONtVX%2FojUFXA%3D&reserved=0
>> >
>> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
>> <aha...@adobe.com.invalid>
>> > wrote:
>> >
>> > > Serkan, is there a bug tracking your layout issue?
>> > >
>> > > There should be a difference between first layout if all
>> children
>> > have
>> > > known sizes and what Greg is describing which is responding
to
>> > children
>> > > changing sizes. I don’t think we’ve dealt with a lot of
>> children
>> > changing
>> > > sizes (other than Images loading late and a few other things)
>> so it
>> > may be
>> > > time to listen to widthChanged/heightChanged/sizeChanged as
>> children
>> > get
>> > > added if there isn’t already code doing that.
>> > >
>> > > There might be other issues with containers having an inner
>> > contentArea
>> > > that might be getting in the way too.
>> > >
>> > > HTH,
>> > > -Alex
>> > >
>> > > From: Yishay Weiss <yishayj...@hotmail.com>
>> > > Reply-To: "dev@royale.apache.org" <dev@royale.apache.org>
>> > > Date: Thursday, June 4, 2020 at 4:30 AM
>> > > To: "dev@royale.apache.org" <dev@royale.apache.org>
>> > > Subject: RE: MXRoyale layout issues - questions/discussion
>> > >
>> > > Call me lazy but this is a bit difficult to parse. If you can
>> spare
>> > some
>> > > time, maybe come up with a GitHub issue that describes a
>> concrete
>> > case so
>> > > we can discuss this.
>> > >
>> > > > I think the layouts work downward for this, but changes in
>> the
>> > children
>> > > don't seem to trigger the parent layout.
>> > >
>> > > Yes, I’ve seen that as well. Alex’s advice when I pointed it
>> out to
>> > him
>> > > was to just add a parent.dispatchEvent(new
>> Event(‘layoutNeeded’)) if
>> > it
>> > > solves a concrete bug. It’s true that this could result in a
>> > performance
>> > > hit. If that’s your issue then I guess we can discuss
>> emulation of
>> > the
>> > > layout manager or some other optimization.
>> > >
>> > >
>> > > From: Greg Dove <greg.d...@gmail.com>
>> > > Sent: Thursday, June 4, 2020 11:12:08 AM
>> > > To: Apache Royale Development <dev@royale.apache.org>
>> > > Subject: MXRoyale layout issues - questions/discussion
>> > >
>> > > Hi,
>> > >
>> > > Just wondered if anyone else is dealing with layout issues in
>> Flex
>> > > emulation. I have some layout issues that are slowing my
>> progress on
>> > a
>> > > project, and I'd like to resolve them as quickly as I can.
>> > >
>> > > In particular, I see issues with BoxLayout-based containers
>> which
>> > have
>> > > percentWidth or percentHeight set. These don't get determined
>> as
>> > having
>> > > width or height 'SizedToContent' when performing layout, but
>> in many
>> > > situations they behave in a similar way (they can change
>> their size
>> > based
>> > > on their content in terms of layout rules applied by the
>> parent
>> > container).
>> > > This is because in Flex, percentages are not simply a
>> percentage of
>> > their
>> > > parent, but they follow something perhaps a little closer to
>> flexbox
>> > layout
>> > > rules for all the percentWidth or percentHeight siblings
>> (managed by
>> > their
>> > > parent's layout). In other words, they are also related to
the
>> > measured
>> > > size of their content if the parent needs to manage them (I'm
>> not
>> > sure how
>> > > best to describe this, but I think that sort of captures it).
>> They
>> > can
>> > > expand beyond their percent allocation or contract below it
>> > depending on
>> > > their measured sizes.
>> > > I think the layouts work downward for this, but changes in
the
>> > children
>> > > don't seem to trigger the parent layout.
>> > >
>> > > An example might be
>> > > <mx:HBox id='addThingsToMe' width='50%' />
>> > >
>> > > If you have the above at the application level (where the
>> > application has
>> > > vertical layout) and keep adding buttons (for example) to the
>> HBox
>> > via a UI
>> > > test button that adds a new Button to that on each click,
>> then it
>> > should
>> > > expand horizontally greater than 50% width when the volume of
>> buttons
>> > > exceeds its nominal 50% width. It is definitely easier to see
>> this
>> > if you
>> > > add a border to the container.
>> > >
>> > > I have been working on this, and made progress, but the
>> approach I
>> > am using
>> > > feels a bit patchwork, and just wondered whether others are
>> seeing
>> > anything
>> > > like this, and/or how it has been addressed elsewhere....
>> > >
>> > > Here's a summary of some of the things I have been trying,
>> which do
>> > yield
>> > > improvements, but don't really solve the problem completely:
>> > >
>> > > 1. added extra listener for 'childrenRemoved' in BoxLayout
>> strand
>> > setter.
>> > >
>> > > 2. Created a new mx 'ContainerView' class
>> > > (mx.containers.beads.ContainerView extends
>> > > org.apache.royale.html.beads.ContainerView)
>> > > This has the following in it:
>> > >
>> > > private var widthBefore:Number = -1
>> > > private var heightBefore:Number = -1;
>> > > private var sizeChangedBeforeLayout:Boolean;
>> > >
>> > > COMPILE::JS
>> > > override public function beforeLayout():Boolean
>> > > {
>> > > var container:Container = host as Container;
>> > >
>> > > sizeChangedBeforeLayout = (widthBefore != container.width ||
>> > heightBefore
>> > > != container.height);
>> > > widthBefore = container.width;
>> > > heightBefore = container.height;
>> > > return super.beforeLayout();
>> > > }
>> > >
>> > > COMPILE::JS
>> > > override public function afterLayout():void
>> > > {
>> > > var container:Container = host as Container;
>> > > //size might change during layout
>> > > var sizeChangedDuringLayout:Boolean =
>> !sizeChangedBeforeLayout &&
>> > > (widthBefore != container.width || heightBefore !=
>> container.height);
>> > > if (sizeChangedDuringLayout) {
>> > > //prepare for next time
>> > > widthBefore = container.width;
>> > > heightBefore = container.height;
>> > > }
>> > > var requestParentLayout:Boolean = sizeChangedBeforeLayout
>> > > || sizeChangedDuringLayout
>> > > || (!isNaN(container.percentWidth) &&
>> container.width <
>> > > container.measuredWidth) || (!isNaN(container.percentHeight)
>> &&
>> > > container.height < container.measuredHeight);
>> > > if (requestParentLayout && container.parent is
>> Container) {
>> > > trace('requesting parent layout of ',(container as
>> > > Object).ROYALE_CLASS_INFO.names[0].qName );
>> > > (container.parent as Container).layoutNeeded();
>> > > }
>> > > }
>> > >
>> > > That is pretty much it, and it is being used as a replacement
>> in my
>> > local
>> > > MXRoyale css for Container:
>> > >
>> > > /*IBeadView:
>> > >
>> ClassReference("org.apache.royale.html.beads.ContainerView");*/
>> > > IBeadView:
>> ClassReference("mx.containers.beads.ContainerView");
>> > >
>> > > I'm not saying this is right, but it does help quite a bit
>> with what
>> > I am
>> > > facing.
>> > >
>> > > In addition to BoxLayout in general, I have been working on
>> the
>> > > Grid/GridRow/GridItem layouts which are more specific in
>> terms of
>> > layout
>> > > changes needed, but also can have similar problems.
>> > >
>> > >
>> > > Although I am seeing improvements with what I have done so
>> far, I'm
>> > not
>> > > really satisfied with it, and I am keen for input/discussion
>> (or
>> > > collaboration). I have been pursuing what I would mostly
>> describe as
>> > a
>> > > 'workaround' approach, so would welcome any thoughts on how
>> best to
>> > tackle
>> > > this.
>> > > I think there is something missing because of the way Flex
>> does
>> > layouts vs.
>> > > the way Royale does it, but I can't describe it fully yet.
>> Perhaps
>> > things
>> > > are only currently envisaged to work with mxml declarative
>> content
>> > onto
>> > > display and not so much with dynamic updates. But I think
>> state-based
>> > > changes could have similar effects for some of these things
>> if they
>> > happen
>> > > inside containers that have their own percent dimensions.
>> > >
>> > >
>> > > Thanks,
>> > > Greg
>> > > From: Greg Dove<mailto:greg.d...@gmail.com>
>> > > Sent: Thursday, June 4, 2020 11:12 AM
>> > > To: Apache Royale Development<mailto:dev@royale.apache.org>
>> > > Subject: MXRoyale layout issues - questions/discussion
>> > >
>> > > Hi,
>> > >
>> > > Just wondered if anyone else is dealing with layout issues in
>> Flex
>> > > emulation. I have some layout issues that are slowing my
>> progress on
>> > a
>> > > project, and I'd like to resolve them as quickly as I can.
>> > >
>> > > In particular, I see issues with BoxLayout-based containers
>> which
>> > have
>> > > percentWidth or percentHeight set. These don't get determined
>> as
>> > having
>> > > width or height 'SizedToContent' when performing layout, but
>> in many
>> > > situations they behave in a similar way (they can change
>> their size
>> > based
>> > > on their content in terms of layout rules applied by the
>> parent
>> > container).
>> > > This is because in Flex, percentages are not simply a
>> percentage of
>> > their
>> > > parent, but they follow something perhaps a little closer to
>> flexbox
>> > layout
>> > > rules for all the percentWidth or percentHeight siblings
>> (managed by
>> > their
>> > > parent's layout). In other words, they are also related to
the
>> > measured
>> > > size of their content if the parent needs to manage them (I'm
>> not
>> > sure how
>> > > best to describe this, but I think that sort of captures it).
>> They
>> > can
>> > > expand beyond their percent allocation or contract below it
>> > depending on
>> > > their measured sizes.
>> > > I think the layouts work downward for this, but changes in
the
>> > children
>> > > don't seem to trigger the parent layout.
>> > >
>> > > An example might be
>> > > <mx:HBox id='addThingsToMe' width='50%' />
>> > >
>> > > If you have the above at the application level (where the
>> > application has
>> > > vertical layout) and keep adding buttons (for example) to the
>> HBox
>> > via a UI
>> > > test button that adds a new Button to that on each click,
>> then it
>> > should
>> > > expand horizontally greater than 50% width when the volume of
>> buttons
>> > > exceeds its nominal 50% width. It is definitely easier to see
>> this
>> > if you
>> > > add a border to the container.
>> > >
>> > > I have been working on this, and made progress, but the
>> approach I
>> > am using
>> > > feels a bit patchwork, and just wondered whether others are
>> seeing
>> > anything
>> > > like this, and/or how it has been addressed elsewhere....
>> > >
>> > > Here's a summary of some of the things I have been trying,
>> which do
>> > yield
>> > > improvements, but don't really solve the problem completely:
>> > >
>> > > 1. added extra listener for 'childrenRemoved' in BoxLayout
>> strand
>> > setter.
>> > >
>> > > 2. Created a new mx 'ContainerView' class
>> > > (mx.containers.beads.ContainerView extends
>> > > org.apache.royale.html.beads.ContainerView)
>> > > This has the following in it:
>> > >
>> > > private var widthBefore:Number = -1
>> > > private var heightBefore:Number = -1;
>> > > private var sizeChangedBeforeLayout:Boolean;
>> > >
>> > > COMPILE::JS
>> > > override public function beforeLayout():Boolean
>> > > {
>> > > var container:Container = host as Container;
>> > >
>> > > sizeChangedBeforeLayout = (widthBefore != container.width ||
>> > heightBefore
>> > > != container.height);
>> > > widthBefore = container.width;
>> > > heightBefore = container.height;
>> > > return super.beforeLayout();
>> > > }
>> > >
>> > > COMPILE::JS
>> > > override public function afterLayout():void
>> > > {
>> > > var container:Container = host as Container;
>> > > //size might change during layout
>> > > var sizeChangedDuringLayout:Boolean =
>> !sizeChangedBeforeLayout &&
>> > > (widthBefore != container.width || heightBefore !=
>> container.height);
>> > > if (sizeChangedDuringLayout) {
>> > > //prepare for next time
>> > > widthBefore = container.width;
>> > > heightBefore = container.height;
>> > > }
>> > > var requestParentLayout:Boolean = sizeChangedBeforeLayout
>> > > || sizeChangedDuringLayout
>> > > || (!isNaN(container.percentWidth) &&
>> container.width <
>> > > container.measuredWidth) || (!isNaN(container.percentHeight)
>> &&
>> > > container.height < container.measuredHeight);
>> > > if (requestParentLayout && container.parent is
>> Container) {
>> > > trace('requesting parent layout of ',(container as
>> > > Object).ROYALE_CLASS_INFO.names[0].qName );
>> > > (container.parent as Container).layoutNeeded();
>> > > }
>> > > }
>> > >
>> > > That is pretty much it, and it is being used as a replacement
>> in my
>> > local
>> > > MXRoyale css for Container:
>> > >
>> > > /*IBeadView:
>> > >
>> ClassReference("org.apache.royale.html.beads.ContainerView");*/
>> > > IBeadView:
>> ClassReference("mx.containers.beads.ContainerView");
>> > >
>> > > I'm not saying this is right, but it does help quite a bit
>> with what
>> > I am
>> > > facing.
>> > >
>> > > In addition to BoxLayout in general, I have been working on
>> the
>> > > Grid/GridRow/GridItem layouts which are more specific in
>> terms of
>> > layout
>> > > changes needed, but also can have similar problems.
>> > >
>> > >
>> > > Although I am seeing improvements with what I have done so
>> far, I'm
>> > not
>> > > really satisfied with it, and I am keen for input/discussion
>> (or
>> > > collaboration). I have been pursuing what I would mostly
>> describe as
>> > a
>> > > 'workaround' approach, so would welcome any thoughts on how
>> best to
>> > tackle
>> > > this.
>> > > I think there is something missing because of the way Flex
>> does
>> > layouts vs.
>> > > the way Royale does it, but I can't describe it fully yet.
>> Perhaps
>> > things
>> > > are only currently envisaged to work with mxml declarative
>> content
>> > onto
>> > > display and not so much with dynamic updates. But I think
>> state-based
>> > > changes could have similar effects for some of these things
>> if they
>> > happen
>> > > inside containers that have their own percent dimensions.
>> > >
>> > >
>> > > Thanks,
>> > > Greg
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
