Hi Darren,
Yes, you and several others are trying to use AIR as a surrogate browser. This
"should" be possible, but AIR has very different security rules than the
browser and those differences have shown up in two ways for you: 1) the styles
problem, 2) the casting of SystemManager problem. So, your code cannot be
used as-is and some adjustments have to be made.
Even if there isn't any communication between SWFs in your app, there sort of
is around the host/showing/sizing/positioning aspect. You found a workaround
by not using strong-typing which is fine, but others attempting this same sort
of conversion may not be satisfied with that so I was hoping you (or someone)
could come up with a test case so we can resolve these problems without
"cheating" and thus make the conversion process better documented for others.
Really, the Styles problem was a form of communication. The StyleManagers
probably were supposed to share or not share something. There might be other
subtle things like that, such as some bubbling event (that isn't a class in the
flash.events.* package) from the subSWF bubbling to the main App and resulting
in TypeErrors for the same reason as the SystemManager issue.
Anyway, if you are happy with the way things are working, that's great.
-Alex
On 9/12/19, 8:33 AM, "DarrenEvans" <darren.ev...@allocatesoftware.com> wrote:
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:
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.2333346.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C531452d6de964c7a451108d737969f2c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637038992371711443&sdata=dinfAbi6pnWqWfur0sigb79SqqDuXA9XJYAa%2BxZb5Gc%3D&reserved=0
