Thursday, July 24, 2008

More AS3 type casting issues...

By:
In a problem somewhat related to my previous post, I've run into a situation where you have a parent SWF loading in a child SWF.

The child SWF has a document class associated with it. The child SWF also has movieclips in its library. These movieclips are exported for Actionscript and are to be dynamically added to a container movieclip on the stage within the child SWF. The dynamic movieclips have their own classname and they extend a custom baseclass.

Code within the child SWF instantiates these dynamic movieclips like so:

var startUp:StartUp() = new StartUp();
this.container_mc.addChild(startUp);


Everything is just fine when compiling the child SWF on its own. The movieclip with classname "StartUp" in the library is added to a container on the stage and it is visible.

The problems arise when you load the child into a parent, casting the loaded DisplayObject to the child's document class. You would normally do this if you wanted the parent to be able to communicate with the child class after it has been loaded in. As long as the parent has an instance of the child class defined somewhere, this is ok.

The problem stems from the fact that if the child is instantiating dynamic movieclips from its library, the code that does this is interpreted when you build the parent SWF only if the parent has an instance of the child class defined. The compiler tries to build the child class from the parent's instance variable and it bombs because it can't see the classnames defined for the dynamic movieclips in the child's library.

If the child SWF doesn't dynamically add movieclips, everything is ok.

There's no way that I know of to allow the parent SWF to know about the static classnames that each dynamic movieclip is defined by within the child SWF.

For now, I've realized that the parent won't need to control the child exclusively once loaded in. Logic contained within the child is enough.

Any thoughts/opinions/solutions would be appreciated.

===

Problem solved. The problem stems from the fact that the dynamic movieclips had a classname that wasn't found when it was set. In this case,

"A definition for this class could not be found in the classpath, so one will be automatically generated in the SWF file upon export."

applies. This is ok if just the child is being compiled. But once you load into a parent, it won't be able to see this class name.

To fix this, you need to create a dummy class using the name you tried to use for the class name. This class must extend the class you originally used for the base class. And instead of the custom base class, YOU MUST USE flash.display.MovieClip for the parent to be able to compile.

4 comments:

Ari Braginsky said...
This comment has been removed by the author.
Ari Braginsky said...
This comment has been removed by the author.
Simon said...

Hi could you elaborate a little on this as I am finding it a little tricky to follow your solution?

Will S. said...

Sounds inconvenient :\

I've been giving some thought to classes that manage these sorts of situations when using a system of hierarchically loaded swfs. This will definitely be something I need to keep in mind while writing it.