Exercising Caution with Pathing and Class Naming in Flash

Recently I was working on a project where I had a container SWF file, which loaded two different SWF files into it. Pretty straight forward stuff, and nothing I haven’t done before. However, my surprise came when I was adding a preloader movieclip in one of the loaded SWF files. Here’s what happened:

In my container SWF, I had a library item set to export with class name “PreloaderMC”. As you might imagine, I created and added this preloader to the stage when my two SWF files were loading, then removed it from the display list once everything was loaded. I also had a library item exporting as “PreloaderMC” in one of my loaded SWF files. When testing and exporting the loaded SWF by itself, there was no issue. However, when I loaded that SWF into the container SWF, the preloader that was created and used in the loaded SWF was the one from the container SWF.

After asking a few colleagues and perusing some of the documentation, this wasn’t necessarily an unexpected find. It all has to do with application domain, which I won’t go into detail about here. In short though, if you use Loader.load() when loading another SWF file, and don’t specify LoaderContext (which, among other things, defines the ApplicationDomain for the loaded object), then the loaded SWF is considered a child domain of the container SWF, and thereby uses whatever class definitions are in the container that may have the same names.

So, lesson learned. Either be more explicit about specifying the application domain when loading external SWF files, or just use unique class names for item that are set to export to ActionScript.

For more information about working with application domains, you can check out the Adobe documentation on working with application domains.

There are no comments yet, add one below.

Leave a Comment