|
Gordon, The reason why I normally set creation
policy to all is to work around flex bugs. Two of them this week:
Sure, I want things to run fast, but
when strange rendering bugs and undefined elements get in the way of getting
something done, setting creation policy to all is a common work around. Best, allen From:
[email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith > On the accordion
tag, set creationPolicy=”all”. > Setting a creationPolicy="All" on the
accordian container will cause all of the "children" to be created
when the accordian is created. In my post two days ago I
tried to explain why setting creationPolicy="all" is not The Right
Way to solve problems caused by deferred instantiation. I'll try to work with
our doc folks to do a better job of explaining the right technique in the
future. In the meantime, here's a repeat of what I wrote then. - Gordon I'd like to
suggest that it's better to learn how to make deferred instantiation
your friend than to simply turn it off. The point of
deferred instantiation is to not waste time at app startup creating controls
that you don't need yet. If you had a ViewStack with 500 views, it
probably wouldn't be a good idea to create the controls on all 500 of them
at startup, when only one view is initially visible. The only good reason
to set creationPolicy="all", and therefore increase startup time, is
to decrease the small navigation delays when you switch from view to
view. If these delays
are acceptable, then you should allow the views to do deferred creation
of their controls, as they were designed to do. So how do you set
the initial state of controls that undergo deferred instantiation?
You use the appropriate events to set their state AFTER they have been
created. For example, you could use 'initialize' or 'creationComplete'
events on the the controls themselves. Or you could use events like
'childrenCreated' or 'childrenCreationComplete' on the view that you
navigated to. Once you realize
that every control in the app doesn't get created at startup, it's
always possible -- and not difficult -- to design your app so that you don't
push information prematurely into controls that don't exist yet.
Instead, it's typical to store information into a "data model" of
some kind that is independent of the controls that display that information.
When the controls get created, they pull the information in
from the data model. From:
This is due to a feature
of Flex known as Deferred Instantiation. My post on Tuesday
entitled "Re: Unable to refer controls in Accordion !" addressed the
issue. - Gordon From:
I am having some problems getting a button on one
panel of an accordion to change the textinput box on another panel of an
accordion and I was wondering if someone can give me some idea as to what could
be causing this? -- -- |
- RE: [flexcoders] Why you shouldn't set creationPolicy="... Allen Manning
- Re: [flexcoders] Why you shouldn't set creationPolicy=... Manish Jethani
- RE: [flexcoders] Why you shouldn't set creationPol... Allen Manning
- RE: [flexcoders] Why you shouldn't set creationPolicy=... Gordon Smith
