The Nordhagen

So after a few headaches I arrived at a thesis (at best): If developing and compiling in Flex Builder, but using a library of assets (in the form of a SWF-file) compiled by the Flash IDE, loading the assets.swf at runtime and embedding are not going to give you equal access the assets and their associated classes. Loading the asset SWF will enable you to use:

loader.contentLoaderInfo.applicationDomain.getDefinition("MySymbolClass")

That will return a class definition of the library symbol and it’s associated custom class and base class.

However:

[Embed(source="assets.swf", symbol="MySymbol")]
var MySymbolClass:Class;

will yield, put simply, the most descriptive, built-in class able to describe the symbol. But that’s at the discretion of the compiler. So if I have a button with an associated custom class, let’s say FancyButton, in assets.swf, that code will be elegantly ingnored by the Flex compiler and I’m only able to datatype the button as Sprite or MovieClip (if it has more than one frame). So I’m guessing the philosophy behind the embed compiler directive is that it is meant for embedding primitive assets, like bitmaps, sprites, fonts and so on into the class that adds the fancy, custom code, while loading and using getDefinition is the only way that will allow the assets to have custom code associated with them.

As seen in the photo comic above from the 70′, this discussion might have been going on for a while without me knowing it. I think I will be loading my asset SWF at runtime from now on unless someone has a good reason for me not to.