I apologize for never responding Adam- I must have lost track of this post-
I found a solid solution to this- Inherit from the container class and override the 'measure' method. See code below: <?xml version="1.0" encoding="utf-8"?> <mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" > <mx:Script> <![CDATA[ public var measureChildren:Boolean = false; protected override function measure():void{ if (this.measureChildren == true){ super.measure(); } else{ //Do nothing; } } ]]> </mx:Script> </mx:VBox> This is the code for my 'SmartVBox' component. When I set the measureChildren to 'false', the control sizes itself correctly in relation to percentage layout within the parent container- if its child controls need more space it will create scrollbars. Set 'measureChildren' to 'true', and it behaves exactly like the regular VBox. Alex, in my Flex experience this is the single most confusing/frustrating thing I've encountered in UI development, as the standard sizing behavior is counter-intuitive (Especially to those coming from Visual .NET). This simple fix took me a while to figure out, and I'm sure it's causing problems for other developers. Maybe incorporate this toggle property into some future version? Thanks all, Yarin --- In [email protected], "aduston1976" <[EMAIL PROTECTED]> wrote: > > Yarin, > > I am struggling with the same issue you report here: Essentially when > I give a Container inheritor percentHeight=100, the Container will > resize itself to fit its children when they become larger than the > Container's parent. This really sucks. Is it true that nobody ever > replied to your message? If so, I would suggest that we spend a little > bit of time looking at the Framework source code so we can figure out > if there's any way around this. Because right now I am hardcoded pixel > values for some VBoxes in my app to work around this. > > Adam > > --- In [email protected], "y_kessler" <y_kessler@> wrote: > > > > Here is a layout issue I've been struggling with for many weeks now: > > > > Essentially, I am looking for a way to size a container component as > > a percentage relative to the space available to it in its parent, and > > with no consideration of the size of its children. > > > > As an example, here's the mxml for an hbox that hosts a vbox that > > hosts a number of dummy components (Taken from an AIR example)... > > <mx:WindowedApplication > > width="400" > > height="300" > > > > > <mx:HBox > > id="hboxMain" > > x="0" > > y="0" > > width="100%" > > height="100%" > > autoLayout="true"> > > > > <mx:VBox > > id="vboxMain" > > width="200" > > height="100%" > > autoLayout="true"> > > <ns1:DummyComponent width="75" height="75"/> > > <ns1:DummyComponent width="75" height="75"/> > > <ns1:DummyComponent width="75" height="75"/> > > </mx:VBox> > > </mx:HBox> > > </mx:WindowedApplication> > > > > I've been coding in Flex for some time now, but frankly I'm still > > confused over the concept of percent sizing. If I assign vboxMain > > height = 100%, it will stretch to fit the available height in its > > parent container, unless the height of its children exceed that > > value, in which case it will stretch beyond the space alloted to it. > > > > I am looking for the following solutions: > > > > a) Can I somehow tell vboxMain to only size according to the space > > available to it in hboxMain (not exceed hboxMain's visible space), > > and to scroll or clip the content of its children? > > b) Is there any way to establish the visible dimensions of a given UI > > component, as opposed to its unscaled/measured/regular dimensions. > > That is, if the vbox is stretched to beyond the space available to > > it, I should at least be able to establish how much of it is visible > > on the screen. > > > > Some final notes: > > > > I've noticed that scrolling/sizing behavior is often different > > depending on whether the dummy controls in this particular example > > are added dynamically or directly in mxml, and whether auto layout > > = "true" is set dynamically. > > > > From what I understand the auto-layout process works from the inside > > out. It's almost as if I'm seeking to reverse this process, so that > > the size of a component's parent drives the layout process instead of > > its children. > > > > I would much appreciate any help you could give me on this topic. > > This has been a major stumbling point for me- > > Thanks! > > > > Yarin > > >

