I have some custom components that at the end of their lifecycle are removed from the display list and "destruct" themselves. By "destruct themselves", I mean that they set various internal references to null.
Anyway, this has caused problems when a component has been queued for layout by the LayoutManager when it's removed from the display list and destructed, and by the time its updateDisplayList() method is called, a lot of stuff it expects to be there is not. I've found various workarounds for this, so it's not really a problem, but it got me to thinking about the implications. There currently seems to be no way to cancel validation of a component by the LayoutManager once it's been queued through one of its invalidateXXX methods. And the LayoutManager doesn't seem to care whether or not a component is on the display list when it's ready to call the appropriate validateXXX method. This is somewhat understandable, because there might be instances when you'd want to layout a component that's not currently on the display list, but I think the common case would be that you wouldn't. In applications where lots of components have their updateDisplayList method called after they're taken off the display list and discarded, the best case is that a lot of cycles will be wasted while the methods execute correctly, and in the worst case they'll throw errors that always seem to hose up the entire application. I think the UIComponent class needs to include a way to prevent all future validations by the LayoutManager, either by setting a flag that the LayoutManager would check, or removing it from the LayoutManager altogether. I don't really have a specific question, but I'd be interested in a response from any Flex engineers who might have an opinion on this. Is there something I'm missing, or misunderstanding?