I'm not sure I understand the current problem. What is the behavior in the
browser/Flash version? Does the "About IBM..." show up in only some context
menus or not at all (probably because context menu modification had different
rules for Flash vs AIR). Their library code might be detecting that it has the
AIR context menu APIs available and modifying the context menu. You might need
to understand how their code is modifying the contextMenu in order to know how
to override their behavior. I think the snippet you posted only shows where
they are getting that string.
FWIW, I would also check your terms-of-use and make sure that you aren't
required to allow that context menu item if you use those components in AIR.
HTH,
-Alex
On 9/13/19, 7:43 AM, "DarrenEvans" wrote:
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:
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.246.n4.nabble.com%2Fdata=02%7C01%7Caharui%40adobe.com%7C032f59d59c1c4a390d3a08d73858c3c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039826205272389sdata=lc5I952X32Mr7YJqiCyR9ZZ%2Ft%2FeE01%2BJEFqW1hQO%2B9s%3Dreserved=0
