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?

Reply via email to