More AS3 type casting issues...

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.

Strange type casting behavior in AS3 when working with parent/child SWF loading.

So I finally solved a little issue I was having with AS3, type casting, and child SWF loading.

Situation: I had a child SWF (C) of custom type com.foo.SomeClass that had its own member variables, etc. I also had a parent SWF (B) that loaded in (C) using the normal loader.content object. Once loaded, this object was cast as type (C).

When I then tried to load (B) into a new parent shell SWF (A), the type cast operation that occurred in (B) on (C) would fail with the error:

TypeError: Error #1034: Type Coercion failed: cannot convert com.foo::SomeClass@34d1d31 to com.foo.SomeClass.

even when inspecting the object to be converted shows that it is an object of type SomeClass:

> someObj: [object SomeClass]

Solution: It turns out that the reason (B) wasn't failing at the type cast operation was because it had its own local variable of type SomeClass defined as part of the type cast operation logic.

Parent SWF (A) did not have this type defined anywhere, either public or private within its own class definition.

Once I added a local variable of type SomeClass within the parent SWF (A) the problem went away.

This has some strange consequences since a parent SWF may simply be implemented as a type of generic "shell" if you will. It may not really need to care about what goes on within its children or children of children that it may be loading.

Based on this behavior, it would seem that the topmost parent SWF would need to have variables defined of all of the possible types that may be used in casting behavior within its children up front.

If anyone has any suggestions/tips on how to prevent having to have the topmost parent SWF from having declared variables of types matching those that may be used in casting operations within child SWFs, I would be happy if you could send me a note.

Thanks.

Lively

My test room on Google's Lively service: