Two Nasty Flex Bugs to Watch Out For

I ran across several bugsfeatures today that I thought would be worthwhile to share. These are of the variety that take a while to figure out and are not very intuitive. Both were encountered using Flex 3.1

Modules Loading Events Never Fire

This one I encountered while manually loading modules using the ModuleManager. Apparently the ModuleManager maintains nothing but weak references to the IModuleInfo object returned using getModule. If you do not maintain a reference to the IModuleInfo object, the object can potentially be garbage collected and any event handlers you added to it will be lost. For instance, the following example will not work as expected:

private function initApp():void {
	var info:IModuleInfo = ModuleManager.getModule("ColumnChartModule.swf");
	info.addEventListener(ModuleEvent.READY, modEventHandler);
 
	info.load();
}
 
private function modEventHandler(e:ModuleEvent):void {
	container.addChild(e.module.factory.create() as ColumnChartModule);
}

In the above example, the IModuleInfo instance will be garbage collected before the modEventHandler method is called. Instead, the above example should be changed to the following:

public var info:IModuleInfo;
 
private function initApp():void {
    info = ModuleManager.getModule("ColumnChartModule.swf");
    info.addEventListener(ModuleEvent.READY, modEventHandler);
 
    info.load();
}
 
private function modEventHandler(e:ModuleEvent):void {
    container.addChild(info.factory.create() as ColumnChartModule);
}

This was actually filed as a bug against flex, but was closed as “Not a bug”, despite the fact that it is a regression from Flex 2.

Tweens Mysteriously Stop and Never Finish

A common pattern when using tweens is the following:

private var _tween:Tween;
 
public function eventHandler(e:Event):void
{
	if(_tween)
	{
		_tween.stop();
	}
 
	// do something and possibly return
 
	_tween = new Tween(...);
	_tween.setTweenHandlers(updateHandler, updateHandler);
}
 
private function updateHandler(c:Number):void
{
	// update something
}

However, when dealing with complex user interfaces that use the above pattern in multiple places simultaneously, I noticed that some Tween instances will stop and never finish, ostensibly at random times. After examining the Flex internal code, I discovered that the logic which manages the Tween objects and invokes their handlers re-uses tween identifiers. Thus, if a Tween has had its stop() method called, its identifier will be reused by future Tween objects. Moreover, if you call the stop() method on a Tween after it has already been stopped, if there is a new Tween which took the identifier of the already stopped Tween, this new Tween will also be stopped by the second stop call.

This fix for this is rigorously make sure that all stop() method calls are called only once, or not at all if the Tween has stopped because it has ended. The above code should be changed to:

private var _tween:Tween;
 
public function eventHandler(e:Event):void
{
	if(_tween)
	{
		_tween.stop();
		_tween = null;
	}
 
	// do something and possibly return
 
	_tween = new Tween(...);
	_tween.setTweenHandlers(updateHandler, finishHandler);
}
 
private function updateHandler(c:Number):void
{
	// update something
}
 
private function finishHandler(c:Number):void
{
	updateHandler(c);
	_tween = null;
}

Flex ScrollPolicy.AUTO Not Good Enough

import mx.core.ScrollPolicy;
public override function validateDisplayList():void
{
    super.validateDisplayList();
 
    if(null != verticalScrollBar && verticalScrollBar.maxScrollPosition == 0
        && verticalScrollPolicy != ScrollPolicy.AUTO)
    {
        verticalScrollPolicy = ScrollPolicy.AUTO;
    }
 
    else if(null != verticalScrollBar)
    {
        verticalScrollPolicy = ScrollPolicy.ON;
    }
}