I think we may have our wires crossed in terms of what we are trying to achieve here.
The Air App is simply a surrogate browser, simply a means to load our existing application SWF. There doesn't need to be any communication between Air App and SWF other than it has a place to host/show it. So having it in it's own Application Domain is perfect for what we need. Alex Harui-2 wrote > 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 -- Sent from: http://apache-flex-users.2333346.n4.nabble.com/
