Runtime Sharing problems solved for good!

March 26th, 2008

I stayed at work until 8:00 pm today because I could not figure out why I was getting a #1065 Reference Error when using Runtime Sharing.

The scenario

A main ActionScript application loads multiple swf files (screens). These swf import various symbols from a central swf (global_asset_library). When I load the first screen, I can see in ServiceCapture that the global_assets_library is requested, because the screen imports assets from it. When I load a second screen that should import assets from the same library, it does not request it, probably because it’s cached. It however displays a #1065 error and leaves a blank where I should have seen my beautiful scenery. So I could not load any subsequent screens because they use Runtime Sharing.

What happened internally?

From good old-fashioned trial-and-error and some incomplete documentation, I figured out that each swf, by default, loads the global_asset_library in its own context (security domain). That means that any other screen is now prohibited from accessing whatever was loaded by the first screen. Our global_asset_library (and I stress Global) now became the sole property of the first screen. Not what we want.

What do we do now?

We use a nice little class called LoaderContext from the flash.system package (AS projects don’t need to be converted to Flex – yay!). This LoaderContext will allow us to load all swf into the application, instead of the swf that requests it.

Show us the code!

var request:URLRequest = new URLRequest(swfPath);
var context:LoaderContext = new LoaderContext();
context.applicationDomain = ApplicationDomain.currentDomain;
var loader:Loader = new Loader();
loader.load(request,context);

Previous: Data Binding expressions Next: .htaccess on Leopard