b-log – betriebsraum weblog

Software Development, Human-Computer Interaction, Projects…

Flash v3 component issues

December 6, 2007

After having worked on a project with Flash’s CS3 component set I guess one could say that they’re much better than their predecessor (after all they’re based on ActionScript 3 now). Some useful components are missing but that’s not too bad as you could create your own based on the v3 core, use Yahoo’s free additions to the v3 set (Astra) or consider using flex if you do a lot of component related work.

Nevertheless there are some problems I’ve encountered while working with some of the existing v3 components (please correct me if I’ve missed something):

1. No destroy / dispose / kill method:
The only way to remove a component is removeChild(myComponent).
I wouldn’t call this a “problem” because maybe it isn’t necessary at all. Maybe cleanup work is done internally when the component is removed from the display list. I’ve just skimmed the component’s sources so I don’t know for sure…but since it’s good practice to add some kind of public dispose() method in ui classes I would have expected a formal way of “disabling” the component before removing it from the display list.

2. No destroy / dispose / kill method in the ICellRenderer interface:
If you write complex cell renderers for Lists, ComboBoxes etc. there’s no method which is called when the CellRenderer is destroyed. A hack to disable all CellRenderers before a List is removed could be:

// cell renderers are contained within this sprite
var itemHolder:Sprite = (myList.getChildAt(3) as DisplayObjectContainer).getChildAt(0) as Sprite;
// dispose each cellRenderer manually
for (var i:int = 0; i < itemHolder.numChildren; i++) {
  (itemHolder.getChildAt(i) as MyCellRenderer).dispose();
}
removeChild(myList);

3. Missing setStyle() method in ICellRenderer interface:
There’s a runtime error when you don’t add the setStyle() method to your own CellRenderer class but setStyle() isn’t part of the ICellRenderer interface definition.

4. Null object references:
Under some circumstances runtime errors are thrown (property / method access of a null object reference). Looking into the UIComponent class revealed that the method getDisplayObjectInstance() (line 1286) returns null when it can’t find a class definition. I think there should be a check against “null” in component classes that use the returned object from getDisplayObjectInstance() before accessing methods on it. (This error probably doesn’t occur unless you load components at runtime and use ApplicationDomains).

5. Redrawing problems:
Sometimes the component doesn’t invalidate / redraw properly. Maybe this has something to do with the stage.invalidate() FlashPlayer bug.

If you know solutions for the above problems please leave a comment…

Filed under: Flex/AS3

3 Responses to “Flash v3 component issues”

  1. Josh Tynjala says:

    One thing that wasn’t made clear in the docs for these components is that you must manually tell subcomponents to redraw by calling drawNow() on them when the parent component is drawing itself. The happens because calls to invalidate() during the validation stage are ignored.

  2. Yes, sometimes you have to force a redraw:

    myButton.drawNow();

    especially when you are instantiating it on the fly. I posted a while back on my experiences with making a custom cell renderer for a List:

    http://www.spintechnologies.ca/flashblog/archives/000108.html

  3. Check out this post from Grant Skinner (architect of the Flash CS3 V3 components) where he exposes a bug in the component framework:

    http://www.gskinner.com/blog/archives/2007/12/cs3_component_b.html

Add a comment

Follow comments to this post by subscribing to the comment feed.