Thanks for the great responses! I see 2 great options here:
- Place my "array" of components that might be needed into a container and change the "creationPolicy" to NONE. Then create the set of components that I need once I discover which set that is using the createComponentFromDescriptor method on the container. This seems to be the option I like best. I can describe the components in the MXML once and then pick and choose which ones get created and added to the UI once I know that information. The only caveat here is that I could end up creating and destroying these components over and over as I change the set that I wish to display, however, these components are very tiny and this shouldn't be expensive. - The other option is to simply create all of the components up front and use the "visible" and "includeInLayout" properties to hide and show the appropriate set of components. This one doesn't cause me to continually create/destroy components like the previous method since I would be simply hiding/showing them. I like this one as well, but am a little partial to the previous which only creates the components that are needed. Then again, these components are tiny. I may go to this method when I get into it, who knows. Thanks again! --- In [email protected], "iilsley" <[EMAIL PROTECTED]> wrote: > > > How about ( and this maybe a complete noobish way :) ) using the > visible attribute .. You then also have to take into account 'layout' > probably .. > -- from LiveDocs --- > Preventing layout of hidden controls > > By default, Flex lays out and reserves space for all components, > including hidden components, but it does not display the hidden > controls. You see blank spots where the hidden controls will appear > when you make them visible. In place of the hidden controls, you see > their container's background. However if the container is any of the > following components, you can prevent Flex from considering the child > component when it lays out the container's other children by setting > the child component's includeInLayout property of the component to false: > > * Box, or any of its subclasses: HBox, VBox, DividedBox, > HDividedBox, VdividedBox, Grid, GridItem, GridRow, ControlBar, and > ApplicationControlBar, > * Form > * Tile and its subclass, Legend > * ToolBar > > When a component's includeInLayout property is false, Flex does not > include it in the layout calculations for other components, but still > lays it out. In other words, Flex does not reserve space for the > component, but still draws it. As a result, the component can appear > underneath the components that follow it in the layout order. To > prevent Flex from drawing the component, you must also set its visible > property to false. > > > > --- In [email protected], "Michael Labriola" <labriola@> > wrote: > > > > > > To add to what Tracy was saying.. > > > > Let's say you have a component in the comps directory called MyComp. > > It could be in MXML or in Actionscript, it doesn't matter. > > > > First you would need to import that component definition by saying > > import comps.MyComp; > > > > Then, at anytime, for instance in response to a button click, you can > > say: > > > > var someVar:MyComp = new MyComp(); > > someVar.property1 = 3; > > someVar.property2 = 7; > > this.addChild( someVar ); > > > > or myViewStack.addChild( someVar ); > > > > You could make a series of functions which create these components > > and set them, calling the appropriate function when needed. Or you > > could dig a little further and learn about factories... is this > > basically what you were trying to do or are we missing your point? > > > > Mike > > > > > > > > --- In [email protected], "Tracy Spratt" <tspratt@> wrote: > > > > > > You understand that if you use navigation containers, like > > viewStack and > > > TabNavigator, that much of this is done for you automatically? > > > > > > > > > > > > Also, separate mxml files is a fine way to make re-useable > > components. > > > Their size is not significant. Make them generic so that you can > > set > > > properties and event listeners. > > > > > > > > > > > > I don't know if the <mx:Component> tag can be used anywhere other > > than > > > in an item renderer(state?), but you might check. > > > > > > > > > > > > And you can instantiate controls at will using container.addChild(). > > > > > > > > > > > > There are also RSLs and modules. > > > > > > > > > > > > Mxml is just another way to write AS classes, use it if you like it. > > > > > > > > > > > > There are lots of options. > > > > > > > > > > > > Tracy > > > > > > > > > > > > ________________________________ > > > > > > From: [email protected] > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of gary_mangum > > > Sent: Tuesday, May 29, 2007 6:30 PM > > > To: [email protected] > > > Subject: [flexcoders] Defining a dynamic UI > > > > > > > > > > > > Is it possible to "pre-define" a set of MXML components but not > > create > > > them or add them to a Container in the application until a later > > time. > > > In other words, I want to define some components, complete with > > > properties, events, etc. that will not be part of my UI until I > > > dynamically add them as the application runs. I will decide whether > > > or not to add them based on runtime criteria. > > > > > > I know that I can use states to add and remove components. If I use > > > states, is there a way to define a component only once in MXML and > > > then add it in 3-4 different states? I do not wish to define my > > > component over and over inside of AddChild tags, and my components > > are > > > not really specialized enough to warrant their own MXML files since > > > there are many of them and the only real differences are their > > > properties, events, etc. > > > > > > I've also thought that I could manually define my components in AS > > and > > > keep them in memory until needed, but would rather define them in > > MXML > > > if possible. I would also like to create the components > > > "just-in'time" instead of creating them up front when they may never > > > be needed. > > > > > > Anyway, thanks for any thoughts on this topic! > > > > > >
