Thanks, Amy. I have decided that my own model is more convoluted than is healthy. So, I have reworked things on my side and stuck with createChildren(). I was tempted to try Mike's suggestion - and, had I felt really good about my implementation, I might have.
At this point, with more checks for null values than ideally there should be, things are working in various scenarios. Thanks again, -Eric --- In flexcoders@yahoogroups.com, "Amy" <[EMAIL PROTECTED]> wrote: > > --- In flexcoders@yahoogroups.com, "Michael Schmalle" > <teoti.graphix@> wrote: > > > > Hi Eric, > > > So, my question is does your approach address this by creating > children > > in > > commitProperties() > > Yes, > > > > This is basically what I do with all renderers in my commercial > components. > > I rarely use createChildren(). The only time I use createChilren() > is when > > the composite is 100% owned by it's parent containing the creation > code. > > > > commitProperties() will solve all timing issues if implemented > correctly. > > > > I'm not quite sure I get what you are asking in the second half > but, all > > item renderers use this algorithm which their state is entirely > dependent on > > the data being pushed into the component either through data or > public > > accessors. > > > > This means that children will not be instantiated until the data is > present > > for their instantiation. > > > > If this doesn't make sense, try to clarify a bit more. > > It's probably better practice to create children in createChildren, > then use commitProperties to do whatever setting of properties needs > to be done, and then use updateDisplayList() to do any layout, and > measure() to resolve any sizing issues. These functions are in place > for very good reasons, and if you try to circumvent them you have a > really good chance of running into problems. > > For instance, if you put child creation logic in commitProperties(), > you are probably going to fail miserably unless you put that logic in > _before_ the super.commitProperties(). That's because any children > should be created prior to commitProperties. And that's the reason > there's a commitProperties() function that's separate from > createChildren(). Oh, and if you do anything that edits layout, > etc., in commitProperties, you better do it _after_ the super. Guess > why? > > You should try and catch her state changes and defer them until the > appropriate moment in the invalidation process. > > If what's going on is that her logic is affecting public properties > or styles that you've exposed on your class, then you just need to > make sure that they set a flag and call the right invalidation method > so that you can execute at the correct place in the invalidation > process. > > HTH; > > Amy >
