You're not wrong! There are other bits and pieces we are working through that
are not working as expected.
If I get some time I'll try and get an example app together to pass on the
knowledge.
Our current problem is we use the "IBM ILOG Elixir" component (now owned by
RogueWave but we still use the IBM swc files) and when hosted in the air app
we get an "About IBM ILOG Elixir" menu whenever we right-click anywhere. The
component has to have been loaded before this happens but once hooked up,
clicking anywhere in the app brings up the menu.
Decompiling our app we see the component doing the following to register the
menu:
//class en_US$ilogsparkutilities_properties
package
{
import mx.resources.*;
public class en_US$ilogsparkutilities_properties extends
mx.resources.ResourceBundle
{
public function en_US$ilogsparkutilities_properties()
{
super("en_US", "ilogsparkutilities");
return;
}
protected override function getContent():Object
{
var loc1:*={"about.elixir":"About IBM ILOG Elixir...",
"about.elixirenterprise":"About IBM ILOG Elixir Enterprise...",
"unsupported.command.CWZEF6006E":"Unsupported Command {0}"};
return loc1;
}
}
}
Any ideas on how we can circumvent this problem?
Alex Harui-2 wrote
> 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
--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/
