Hello.
In our code, someone has implemented a custom spark text area, that
attempts to resize based on the number of lines in the text.
Snippet-ish:
<s:TextArea updateComplete="updateCompleteHandler(event)" ... >
...
private function updateCompleteHandler(event:FlexEvent):void {
textFlow.flowComposer.composeToPosition();
var actualNumOfLines: int = textFlow.flowComposer.numLines;
heightInLines = actualNumOfLines;
}
This is then used in a form on a popup. It all works as desired. However,
in trying to track down an enormous memory leak, I think this component
with LayoutManager is responsible.
It seems that if this handler is called - but the component is not on the
screen (it's on the bottom of the popup form, hidden by a scrollbar), then
things go wrong. The
heightInLines = <value>
calls invalidateProperties, which causes the global LayoutManager to add
the component into several priorityqueues. When the dialog is finished,
and I haven't made the control visible (by scrolling) at any point, the
control is still in that priorityqueue (the invalidatePropertiesQueue),
nothing gets released, boom - massive memory leak (which additionally does
not seem to show up in the flex profiler).
Is this a bug? Are there some other rules around cleaning up the layout
manager, or not calling invalidate functions ? Whilst I can work around
this issue in this instance, I'm slightly concerned there are other
instances of controls that are never added which might exhibit the same
behaviour...
