SWFLoader not pulling through all sub SWF styles

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

SWFLoader not pulling through all sub SWF styles

DarrenEvans
Not sure if this forum is still as active as it once was but I'll give it a
go.......

We have a massive Flex application that we are probably not going to have
converted to HTML/JS by the time FlashPlayer is turned off at the end of
2020.

So as a stop gap solution we are going to try the locally installed Air App
that downloads and the loads in the old SWF file (I see from previous posts
this seems to be a popular approach).

I'm using the "download SWF as bytes and load into a SWFLoader" approach. In
a condensed form, basically this:

        private function loadExternalSwfViaBytes(swfUrl:String):void {
                var urlRequest:URLRequest = new URLRequest(swfUrl);
                var urlLoader:URLLoader = new URLLoader();
                urlLoader.dataFormat = URLLoaderDataFormat.BINARY;
                urlLoader.addEventListener(Event.COMPLETE, UrlLoaderComplete);
                urlLoader.load(urlRequest);
        }

        private function UrlLoaderComplete(event:Event):void {
                try {
                        var loader:URLLoader = URLLoader(event.target);
                        var context:LoaderContext = new LoaderContext();
                        context.allowLoadBytesCodeExecution = true;
                        swfLoader.loaderContext = context;
                        swfLoader.load(loader.data);
                } catch (e:Error) {
                        logEvent("UrlLoaderComplete Failed: " + e.message);
                }
        }

The SWF successfully loads but not all the styles and skins from the SWF are
being used. Styles and skins from the loading app are used instead. There
are LOADS of styles and skins and it's not possible to load them all in the
launching app.

Is there anything that can be done to ensure all the styles and skins from
the loaded SWF get used?



--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

Alex Harui-2
IIRC, this has to do with the ApplicationDomain specified in the LoaderContext.  In the currently running Flash app, what ApplicationDomain settings are being used?
I think you will need to use the same settings with loadBytes.

Also, IIRC, if you were loading SWFs into a separate security sandbox on purpose (which would have the effect of each child SWF having its own styles), then you may have to explicitly set up a separate ApplicationDomain when using loadBytes.  And also note that loadBytes breaks the security sandbox so if you were relying on a security sandbox you no longer have one when using loadBytes and you should just be able to load the SWF in AIR without loadBytes and it should get its own security sandbox.

It has been so long since I answered questions on this topic that I could certainly be wrong...

HTH,
-Alex

On 9/6/19, 10:53 AM, "DarrenEvans" <[hidden email]> wrote:

    Not sure if this forum is still as active as it once was but I'll give it a
    go.......
   
    We have a massive Flex application that we are probably not going to have
    converted to HTML/JS by the time FlashPlayer is turned off at the end of
    2020.
   
    So as a stop gap solution we are going to try the locally installed Air App
    that downloads and the loads in the old SWF file (I see from previous posts
    this seems to be a popular approach).
   
    I'm using the "download SWF as bytes and load into a SWFLoader" approach. In
    a condensed form, basically this:
   
    private function loadExternalSwfViaBytes(swfUrl:String):void {
    var urlRequest:URLRequest = new URLRequest(swfUrl);
    var urlLoader:URLLoader = new URLLoader();
    urlLoader.dataFormat = URLLoaderDataFormat.BINARY;
    urlLoader.addEventListener(Event.COMPLETE, UrlLoaderComplete);
    urlLoader.load(urlRequest);
    }
   
    private function UrlLoaderComplete(event:Event):void {
    try {
    var loader:URLLoader = URLLoader(event.target);
    var context:LoaderContext = new LoaderContext();
    context.allowLoadBytesCodeExecution = true;
    swfLoader.loaderContext = context;
    swfLoader.load(loader.data);
    } catch (e:Error) {
    logEvent("UrlLoaderComplete Failed: " + e.message);
    }
    }
   
    The SWF successfully loads but not all the styles and skins from the SWF are
    being used. Styles and skins from the loading app are used instead. There
    are LOADS of styles and skins and it's not possible to load them all in the
    launching app.
   
    Is there anything that can be done to ensure all the styles and skins from
    the loaded SWF get used?
   
   
   
    --
    Sent from: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.2333346.n4.nabble.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7Ca58b9fd41a4f476b4ba208d732f32585%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637033892198156774&amp;sdata=Y12RsZ%2BhiuK5y8ZpQrhTlqd%2BsNZ2npZQl5fHzGp%2FOhY%3D&amp;reserved=0
   

Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

DarrenEvans
I played around with various of these techniques and they all present
different problems. Loading the child SWF into its own Application Domain
sorts out the styling problem but presents a different problem. Upon resize
nothing happens; the child SWF remain the same size or scales rather than
resizing (depending on SWFLoader settings).

I found this old post you commented on:
https://forums.adobe.com/thread/430250
<https://forums.adobe.com/thread/430250>  

I'm not sure what you mean when you say "It might be worth it to implement
IFlexDisplayObject.". The child SWF is an mx:Application which already
implements that interface via its class hierarchy. Do you mean the launching
application?



--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

Alex Harui-2
That thread I think is about loading a child SWF that was not a Flex Application.

Let's collect some information first:
-What version of Flex are you using for the browser version?
-Are you using the same version of Flex for the AIR version?
-What is the URL of the main SWF?
-What is the URL of the sub SWF?
-What does the SWFLoader MXML tag (or AS equivalent) look like in the browser version?

If you can't post your code as-is, anything sensitive can probably be obfuscated.

If you can create a simple test case that works in the browser but not in AIR that might help as well.

I can't immediately think of any constraints in AIR that don't allow it to duplicate loading subSWFs like Flash can, other than the default security rules.  IIRC, by default, in Flash, a SWF loaded from the same domain from some child folder is in the same security context and gets a child ApplicationDomain topology.  In AIR, a SWF loaded from a server or folder outside of the application folder are put in different security contexts (like cross-domain loading).  The loadBytes trick puts the SWF bytes in the same security context, but does not default to a child ApplicationDomain topology.  I think some aspects of Flex styles count on a child ApplicationDomain topology.

You can dump out the ApplicationDomain topology I think by accessing the systemManagers in SystemManagerGlobals.

HTH,
-Alex

On 9/9/19, 1:43 AM, "DarrenEvans" <[hidden email]> wrote:

    I played around with various of these techniques and they all present
    different problems. Loading the child SWF into its own Application Domain
    sorts out the styling problem but presents a different problem. Upon resize
    nothing happens; the child SWF remain the same size or scales rather than
    resizing (depending on SWFLoader settings).
   
    I found this old post you commented on:
    https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforums.adobe.com%2Fthread%2F430250&amp;data=02%7C01%7Caharui%40adobe.com%7Cda33622635514146a84f08d73501bf12%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036153961495380&amp;sdata=uDcpoeliFB0XKlN3PW6AYlYKk4D3Ns8f0IMRQwAfuao%3D&amp;reserved=0
    <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforums.adobe.com%2Fthread%2F430250&amp;data=02%7C01%7Caharui%40adobe.com%7Cda33622635514146a84f08d73501bf12%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036153961505373&amp;sdata=B4%2BvAdyPWCuADTlylzsN%2FdZvjXXAfz0x9Ls8sOJzieA%3D&amp;reserved=0>  
   
    I'm not sure what you mean when you say "It might be worth it to implement
    IFlexDisplayObject.". The child SWF is an mx:Application which already
    implements that interface via its class hierarchy. Do you mean the launching
    application?
   
   
   
    --
    Sent from: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.2333346.n4.nabble.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7Cda33622635514146a84f08d73501bf12%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036153961505373&amp;sdata=W2S4fL9bqvtVRQNrZpc2nwKeRpghEmrQJFqbrUE1aTs%3D&amp;reserved=0
   

Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

DarrenEvans
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: http://apache-flex-users.2333346.n4.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Access to CheckBox in a DataGrid

npem
Hi everyone,

Not used Flex/AS3 for some time and am after some information.

If anyone can help:
I have a Spark dataGrid with:
Column1 = some text
Column2 = Checkbox

I wish to check to checkbox when any part of the row is clicked.
Now I know which row has been clicked, but how the hell do I set the
checkBox to be checked/unchecked.

FYI:
I am using FlexSDK 4.16 and AIR SDK 29.0.0.122

Many thanks to anyone who can reply

CODE:
==============================

[Bindable]
public var countryData:ArrayCollection = new ArrayCollection
([
   {value:"France", code:0},
   {value:"Japan", code:0},
   {value:"India", code:1},
   {value:"Russia", code:0},
   {value:"United States", code:0}
]);


private function selectionChangingHandler(evt:MouseEvent):void
{
   trace("Row Selected = " + dg.selectedIndex);
}

==============================


<s:DataGrid id="dg" width="85%" editable="false"
dataProvider="{countryData}"
           selectionColor="yellow" sortableColumns="false" enabled="true"
           click="selectionChangingHandler(event)">
   <s:columns>
       <s:ArrayCollection>
           <s:GridColumn  dataField="value" headerText="Country"
width="90%" editable="false"/>

           <s:GridColumn headerText="Delete" dataField="active"
rendererIsEditable="true" width="15%" editable="true">
               <s:itemRenderer>
                   <fx:Component>
                       <s:GridItemRenderer>
                           <s:CheckBox id="cb1" selected="false"
horizontalCenter="0" verticalCenter="3"/>
                       </s:GridItemRenderer>
                   </fx:Component>
               </s:itemRenderer>
           </s:GridColumn>

       </s:ArrayCollection>
   </s:columns>
</s:DataGrid>

==============================

Phil.

Reply | Threaded
Open this post in threaded view
|

Re: Access to CheckBox in a DataGrid

Olaf Krueger
Hi,

one way is to introduce a boolean flag, e.g. 'checked' within your data
model which is 'countryData'.
After clicking a row, you have to set this flag to 'true' for the related
row.

Within the item renderer, you have to evaluate the 'checked' property in
order to update the 'selected' property of the checkbox.

Hope this helps!

Olaf





--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/
Reply | Threaded
Open this post in threaded view
|

AW: SWFLoader not pulling through all sub SWF styles

jan.weber
In reply to this post by DarrenEvans
I'm not sure if this helps but I recently loaded an SWF into a Flex app and had problems with accessing the root timeline of that SWF.
Other than what I read in the web (simply accessing the "content" property of the SWFLoader) I had to go deeper which resulted in the following construct:

(((swfAnimation.content as MovieClip).getChildAt(0) as Loader).content as MovieClip).someFunction()

"swfAnimation" is of type spark SWFLoader.
Maybe this helps.







Mit freundlichen Grüßen / Best Regards
i.A. Jan Weber
Software Development



Contact:


Location:


Head & Accounts Office:


tel


+49 941 8700 326


Bahnhofstr. 16


Bahnhofstr. 16


fax



93047 Regensburg


93047 Regensburg


mail


[hidden email]<mailto:[hidden email]>


Germany


Germany


[banner]
<http://www.dallmeier.com/index.php?id=1054>


Subscribe to our Newsletter<http://www.dallmeier.com/index.php?id=322&L=1>


www.dallmeier.com<http://www.dallmeier.com/en/home.html>


Social Media<http://www.dallmeier.com/index.php?id=292&L=1>



Dallmeier electronic GmbH & Co.KG

CEO:
Registry Court:
VAT ID:
Unlimited Partner:
Registry Court:


         Dieter Dallmeier
         Amtsgericht Regensburg HRA 6827
         DE813790649
         Dallmeier GmbH
         Amtsgericht Regensburg HRB 9085





-----Ursprüngliche Nachricht-----
Von: DarrenEvans <[hidden email]>
Gesendet: Mittwoch, 11. September 2019 12:30
An: [hidden email]
Betreff: Re: SWFLoader not pulling through all sub SWF styles

ACHTUNG: Diese Mail kommt von einem externen Absender. Bitte behandeln Sie alle Dateianh?nge und Links mit besonderer Vorsicht. Im Zweifel wenden Sie sich bitte an die IT.

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: http://apache-flex-users.2333346.n4.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Access to CheckBox in a DataGrid

Alex Harui-2
In reply to this post by Olaf Krueger
Another way is to have a custom renderer that checks its index and the DataGrid's selectedIndex and decides whether to display the check or not.  The index and reference to the DataGrid are in the "listData" property of a custom IDropInListItemRenderer (which is of type DataGridListData).

I'm not sure one way is better than the other.  Also, some folks don't even use a real CheckBox, they just display the graphic.

-Alex

On 9/11/19, 4:40 AM, "Olaf Krueger" <[hidden email]> wrote:

    Hi,
   
    one way is to introduce a boolean flag, e.g. 'checked' within your data
    model which is 'countryData'.
    After clicking a row, you have to set this flag to 'true' for the related
    row.
   
    Within the item renderer, you have to evaluate the 'checked' property in
    order to update the 'selected' property of the checkbox.
   
    Hope this helps!
   
    Olaf
   
   
   
   
   
    --
    Sent from: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.2333346.n4.nabble.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7Cbab8d033570a4a1f231408d736acd277%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637037988247042278&amp;sdata=RGG2W7C5DQMeDrHhOScXMDBhDIRO87w6S2P4ZMrWJfc%3D&amp;reserved=0
   

Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

Alex Harui-2
In reply to this post by DarrenEvans
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" <[hidden email]> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C55e74a53fbaf440df13d08d736a30742%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637037946150482474&amp;sdata=%2FCcsNh70ONsOMFqtzBmFiGlGqo3XGhWe%2FKYaGHBy5fk%3D&amp;reserved=0
   

Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

DarrenEvans
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/
Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

Alex Harui-2
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" <[hidden email]> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C531452d6de964c7a451108d737969f2c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637038992371711443&amp;sdata=dinfAbi6pnWqWfur0sigb79SqqDuXA9XJYAa%2BxZb5Gc%3D&amp;reserved=0
   

Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

DarrenEvans
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/
Reply | Threaded
Open this post in threaded view
|

Re: SWFLoader not pulling through all sub SWF styles

Alex Harui-2
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" <[hidden email]> 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.2333346.n4.nabble.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7C032f59d59c1c4a390d3a08d73858c3c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039826205272389&amp;sdata=lc5I952X32Mr7YJqiCyR9ZZ%2Ft%2FeE01%2BJEFqW1hQO%2B9s%3D&amp;reserved=0