Container is definitely only for a base class, it will always measure() to 0,0 and leave all added children as 0x0 at 0,0.
You could probably use it in the following situation: 1. You need to be using some sort of container for whatever reason (ie adding it to something that only takes other containers) 2. You specify its width and height either explicitly or with CSS 3. You specify the width, height, and position of all its children explicity. IE, it's not much use as a container ;-) -Josh On Thu, Jun 19, 2008 at 1:04 PM, Richard Rodseth <[EMAIL PROTECTED]> wrote: > Thanks. That's good to know about Box. > I believe Container is intended to be an abstract class, and while I was > able to use it as the root of an MXML document, it didn't seem to do > anything sensible (i.e. I couldn't see the children). > > I guess if I was assured that Canvas is not horribly heavyweight (in speed > and memory footprint) relative to Box, that would be my preference, since I > can then avoid adding interim children in many cases. And a VBox nested > in/on a Canvas seems more intuitive than a Canvas nested in a Box. > > > On Wed, Jun 18, 2008 at 4:06 PM, Enjoy Jake <[EMAIL PROTECTED]> wrote: > >> Actually, a box with only one child is optimized to layout extremely >> efficiently, so this is not a bad solution. Another possibility would be to >> use the Container class. >> >> >> ----- Original Message ---- >> From: Richard Rodseth <[EMAIL PROTECTED]> >> To: "[email protected]" <[email protected]> >> Sent: Wednesday, June 18, 2008 4:00:48 PM >> Subject: [flexcoders] Application components - Canvas vs Box >> >> I tend to have quite a few MXML application components in my >> applications. Some are for re-use purposes, some are templates, some are for >> wiring together MVC triads, others are just for organization. I haven't >> noticed any performance issues due to the "extra" containers, some of which >> may have a single child providing the actual desired layout. I tend not to >> subclass components in ActionScript (though I obviously have plenty of other >> ActionScript classes, and a couple of custom components) >> >> I've also tended to use a lot of VBoxes and HBoxes in my layouts, though >> I'm using Canvases more and more. >> >> I've tended to make each MXML component a VBox, sometimes changing them >> after the fact. But I'd rather just have an "organizational" root component >> that can have a script block and do whatever non-layout binding stuff I >> want, with a single child responsible for layout. i.e. less editing of the >> first few lines in the file. Something like mx:Module without the layout >> rules, I guess. The reader would skim over the small-as-possible script >> block, and see a first tag indicating the type of layout. >> >> I see a couple of possibilities: >> - Make each app component a Canvas, meaning I can dive in and position >> children absolutely and with constraints, but it also has the nice default >> of sizing to contain children, just like Box. Will often be adding a single >> VBox or HBox child. This is the way I'm leaning, but I'm not sure how >> heavyweight Canvas is compared to Box. >> - Box (editing direction as needed, or adding canvases or nested boxes) >> - Custom. Is it possible to write a custom component that can be the root >> of an MXML file? It would be the simplest possible container, like a >> Box-of-one. >> >> I'm interested to hear the practices of others. >> >> >> >> > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
