Runtime Sharing problems solved for good!
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.
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);