The removeChild handling does not unregister the component from the validation scheme, so it will get validated if it got invalidated before or during its removal.
Usually, cleaning up everything is unnecessary; nulling out a few high level pieces should be good enough, and will avoid such problems. If you start cleaning up in the low-level, you run the risk of invalidating the component in doing so. -Alex From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Amy Sent: Friday, November 07, 2008 9:29 AM To: [email protected] Subject: [flexcoders] Re: callLater calls from flex --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, "christian.menzinger" <[EMAIL PROTECTED]> wrote: > > Hi all, > > I have a very special problem: > > By selecting an item in my navigation I start rendering my view with > several display objects (container, components, ...). > > Everytime I select an other item, I remove all stuff from display list > (destroying all bindings, remove all listeners, setting everything to > null). > > If I do very quick changes, after a while I receive null-pointer > exceptions in different classes in different validation methods > (measure / updateDisplayList) like > > TypeError: Error #1009: Cannot access a property or method of a null > object reference. > at package::ClassName/updateDisplayList()[ClassName.as:490] ... > That brings me to the following questions: > - Could it be true that flex forces validation via callLater even if > the instance is removed? How could this be? > - If so, how can I solve the problem proper (e.g. remove all > callLaters in my destroy functions -> btw: there is a mx_internal > function cancelAllCallLaters() in UIComponent but that is not working > for me -> no effect if I call this function in my destroy functions) > - Or am I completely wrong and the problem is part of my custom > components development? > > If you have any ideas or solutions which can guide me in the right > direction would be very cool. The invalidation mechanism used by nearly all components is already using a form of callLater. So you should work within it so as not to fall afoul of it. I'm suspecting that the proper place for what you're doing is in updateDisplayList(), but you may also want to consider looking at commitProperties() as well. HTH; Amy
