It is all about the ApplicationDomain topology. By loading the sub
application's SWF into its own ApplicationDomain, the subApplication has its
own definition of SystemManager which is not the same definition as the main
Application's SystemManager. You can almost think of an ApplicationDomain as a
decorator on the runtime's class identifier (the qualified name may be
mx.managers.SystemManager for both), but the runtime has effectively stored
them as mx.managers.SystemManager@MainSWF and mx.managers.SystemManager@SubSWF.
And thus, the cast will fail.
I'm pretty sure the reason the styles were having a problem is also due to some
expectations about ApplicationDomain topology. By default, SWFLoader in the
browser sets up a topology you have not mentioned, which is a "child
ApplicationDomain" topology. So far it sounds like you tried loading into the
main ApplicationDomain and having a separate ApplicationDomain, but your
browser app was loading into a child ApplicationDomain so that classes that
both SWFs had would use the main app's definition and classes unique to the
subSWF would be in their own AppDomain. The style code might have expectations
about that. That's why having a simple test case would be useful. It would
hopefully let us write a blog post that says "if you are converting SWFLoader
from Browser to AIR, here is what you need to change".
In your current separate AppDomain topology, you may find more issues passing
data types between the SWFs.
HTH,
-Alex
On 9/11/19, 3:30 AM, "DarrenEvans" <darren.ev...@allocatesoftware.com> wrote:
We are using Flex SDK 4.6.0.23201 (with built in AIR SDK 3.1.0.4880) for
both
the Air application host and the SWF being loaded.
We gave up on the styling problem (loading the SWF in to the same
application domain).
We swapped it to load in to it's own application domain, ala:
*var appDomain:ApplicationDomain = new ApplicationDomain();*
var loader:URLLoader = URLLoader(event.target);
var context:LoaderContext = new LoaderContext(false, *appDomain*);
context.allowLoadBytesCodeExecution = true;
swfLoader.loaderContext = context;
swfLoader.addEventListener(Event.COMPLETE, loadComplete);
swfLoader.load(loader.data);
Doing this reintroduced the problem (we'd already been down this road) of
resizing. Once the app had loaded the SWF it was impossible to get it to
resize the content.
We solved this by subclassing SWFLoader and adding a new method (which has
access to the real content):
public function changeSize(height: Number, width: Number):void {
if (contentHolder is FlexLoader) {
const sm:DisplayObject =
FlexLoader(contentHolder).content as
DisplayObject;
if (sm) {
sm["setActualSize"](width, height);
sm["application"]["setActualSize"](width,
height);
}
}
}
We did stumble initially on this as we wanted to cast
FlexLoader(contentHolder).content directly to a SystemManager. However, even
though it looks like a SystemManager in the debugger the cast fails. Using
reflection to call setActualSize on the content (and its application) works
though.
We were baffled by this and could only assume it was something to do with
how the SWF file is configured/merged/built.
Any ideas on why that cast would fail?
--
Sent from:
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.2333346.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C55e74a53fbaf440df13d08d736a30742%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637037946150482474&sdata=%2FCcsNh70ONsOMFqtzBmFiGlGqo3XGhWe%2FKYaGHBy5fk%3D&reserved=0
