Two Nasty Flex Bugs to Watch Out For

gordon — Wed, 05 Nov 2008 21:52:54 +0000

I ran across several ~~bugs~~features 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

gordon — Fri, 23 May 2008 23:26:33 +0000

One of my biggest gripes so far with the flex scrolling system is the automatic scrolling policy: a container’s viewing area is not changed by the introduction of scroll bars. This is especially troublesome in the vertical case and seems to be a pretty shitty way of doing things in general. For example, if the vertical size of the children increases beyond the height of their container, a vertical scroll bar will be created and displayed, however the children will not be resized. Consequently, if some of the children have variable widths (e.g. width=”100%”), they may be overlapped by the vertical scroll bar, causing a horizontal scroll bar to be displayed. When the scrolling policy is set to ScrollPolicy.ON, however, the children are resized to take the scroll bar into account at the price of the scroll bar always displaying, even when it is not needed. Yuck. I have heard several justifications for this. One is that it prevents a cascading resize effect where all the descendants of the container are resized, each one introducing a vertical scroll bar. Another is that it is faster due to the fact that it requires only a single pass on the children, whereas to do it the correct way would require sizing the children, checking if scroll bars are required, and then adjusting the size of the children based on the new size when scroll bars are introduced. In both cases the justification is entirely dwarfed by the current behavior. Fortunately there is a fix for this: create a custom container and add the following override for the validateDisplayList method:

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

This is a hack which toggles between ScrollPolicy.AUTO and ScrollPolicy.ON as needed to gain the desired behavior. It comes at the price of invalidating the verticalScrollPolicy property. Hopefully this behavior will be more tightly integrated into future versions of Flex (maybe another ScrollPolicy is in order?).

Gordon's Blog » bug

Two Nasty Flex Bugs to Watch Out For

Modules Loading Events Never Fire

Tweens Mysteriously Stop and Never Finish

Flex ScrollPolicy.AUTO Not Good Enough