Board report time (September 2019)

2019-09-12 Thread Olaf Krueger
Hi guys,
it's board report time!

I've created the September 2019 report here [1].
Please take a look at it and add or change things if needed!

Unfortunately, I am too late, the report has to be sent until Wed September
11th.

Thanks,
Olaf

[1]
https://cwiki.apache.org/confluence/display/FLEX/September+2019



--
Sent from: http://apache-flex-users.246.n4.nabble.com/


Re: Board report time (September 2019)

2019-09-12 Thread Carlos Rovira
Hi Olaf,

for me its all ok.
thanks!

Carlos



El jue., 12 sept. 2019 a las 10:30, Olaf Krueger ()
escribió:

> Hi guys,
> it's board report time!
>
> I've created the September 2019 report here [1].
> Please take a look at it and add or change things if needed!
>
> Unfortunately, I am too late, the report has to be sent until Wed September
> 11th.
>
> Thanks,
> Olaf
>
> [1]
> https://cwiki.apache.org/confluence/display/FLEX/September+2019
>
>
>
> --
> Sent from: http://apache-flex-users.246.n4.nabble.com/
>


-- 
Carlos Rovira
http://about.me/carlosrovira


Re: Board report time (September 2019)

2019-09-12 Thread Olaf Krueger
Hi,

because we're in a hurry, I just submitted the report.
Thanks, Carlos and Piotr (at dev) for reviewing!

Olaf



--
Sent from: http://apache-flex-users.246.n4.nabble.com/


Re: SWFLoader not pulling through all sub SWF styles

2019-09-12 Thread 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.246.n4.nabble.com/


Re: SWFLoader not pulling through all sub SWF styles

2019-09-12 Thread Alex Harui
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"  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.246.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C531452d6de964c7a451108d737969f2c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637038992371711443&sdata=dinfAbi6pnWqWfur0sigb79SqqDuXA9XJYAa%2BxZb5Gc%3D&reserved=0




Re: Apache Flex SDK Installer Validation Error

2019-09-12 Thread Jeff Gomes
Did the checksums change again?  Installation aborted today.  Flex SDK 
4.16.1, AIR 32, MacOS Mojave.


   Validating download: /Applications/Apache
   Flex/4.161air32/frameworks/libs/player/32.0/playerglobal.swc

   Flash SDK download failed

   Installation aborted:
   http://flex.apache.org/track-installer.html?failure=true&label=Apache
   Flex SDK
   
4.16.1&version=4.16.1&os=mac&installerversion=3.3.2&info=&info=Flash%20SDK%20download%20failed

~ Jeff

On 8/21/19 23:33, Alex Harui wrote:

Try it again.  The checksums did change so I updated them.

-Alex

On 8/21/19, 7:23 PM, "Velocedge"  wrote:

 I am getting a similar error on Windows:
 
 Validating download:

 D:\Software\Flex\SDK\latest/frameworks/libs/player/32.0/playerglobal.swc
 Flash SDK download failed
 Installation aborted:
 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflex.apache.org%2Ftrack-installer.html%3Ffailure%3Dtrue%26label%3DApache&data=02%7C01%7Caharui%40adobe.com%7C5b398fcc24fb4fad60cf08d726a7bbc4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637020374160143919&sdata=oLB8XWrYUurG0O%2FZSmKf7eAo%2FdUmc6BIIXq%2B4a4eKGc%3D&reserved=0
 Flex
 SDK
 
4.16.1&version=4.16.1&os=windows&installerversion=3.3.2&info=&info=Flash%20SDK%20download%20failed
 
 Is this just a checksum issue?  It's been a month since John posted his

 issue.  Is there something I can to do help?
 
 
 
 --

 Sent from: 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.246.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C5b398fcc24fb4fad60cf08d726a7bbc4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637020374160153913&sdata=9GQEkyA6OVtGgSF1BkfaD7Lobx3FsD4bkTcasZc67YE%3D&reserved=0
 





Re: Apache Flex SDK Installer Validation Error

2019-09-12 Thread Alex Harui
Yes, looks like they did.  I just pushed an update so try again.

Thanks,
-Alex

On 9/12/19, 4:16 PM, "Jeff Gomes"  wrote:

Did the checksums change again?  Installation aborted today.  Flex SDK 
4.16.1, AIR 32, MacOS Mojave.

Validating download: /Applications/Apache
Flex/4.161air32/frameworks/libs/player/32.0/playerglobal.swc

Flash SDK download failed

Installation aborted:

https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflex.apache.org%2Ftrack-installer.html%3Ffailure%3Dtrue%26label%3DApache&data=02%7C01%7Caharui%40adobe.com%7C273ce1c1602c4009d2c708d737d74434%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039270013535645&sdata=h4q30uwXiXETcKWuqs%2B4znSV0FyaPHWm0zlXwidMnIc%3D&reserved=0
Flex SDK

4.16.1&version=4.16.1&os=mac&installerversion=3.3.2&info=&info=Flash%20SDK%20download%20failed

~ Jeff

On 8/21/19 23:33, Alex Harui wrote:
> Try it again.  The checksums did change so I updated them.
>
> -Alex
>
> On 8/21/19, 7:23 PM, "Velocedge"  wrote:
>
>  I am getting a similar error on Windows:
>  
>  Validating download:
>  
D:\Software\Flex\SDK\latest/frameworks/libs/player/32.0/playerglobal.swc
>  Flash SDK download failed
>  Installation aborted:
>  
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflex.apache.org%2Ftrack-installer.html%3Ffailure%3Dtrue%26label%3DApache&data=02%7C01%7Caharui%40adobe.com%7C273ce1c1602c4009d2c708d737d74434%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039270013535645&sdata=h4q30uwXiXETcKWuqs%2B4znSV0FyaPHWm0zlXwidMnIc%3D&reserved=0
 Flex
>  SDK
>  
4.16.1&version=4.16.1&os=windows&installerversion=3.3.2&info=&info=Flash%20SDK%20download%20failed
>  
>  Is this just a checksum issue?  It's been a month since John posted 
his
>  issue.  Is there something I can to do help?
>  
>  
>  
>  --
>  Sent from: 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.246.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C273ce1c1602c4009d2c708d737d74434%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039270013535645&sdata=jUlp55v09uA%2Bb20Dm%2BFd%2F3wNoAcxtCYAPv%2BvPTR8Vhs%3D&reserved=0
>  
>





Re: Apache Flex SDK Installer Validation Error

2019-09-12 Thread Jeff Gomes

That did the trick.  Thank you!

~ Jeff

On 9/12/19 19:22, Alex Harui wrote:

Yes, looks like they did.  I just pushed an update so try again.

Thanks,
-Alex

On 9/12/19, 4:16 PM, "Jeff Gomes"  wrote:

 Did the checksums change again?  Installation aborted today.  Flex SDK
 4.16.1, AIR 32, MacOS Mojave.
 
 Validating download: /Applications/Apache

 Flex/4.161air32/frameworks/libs/player/32.0/playerglobal.swc
 
 Flash SDK download failed
 
 Installation aborted:

 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflex.apache.org%2Ftrack-installer.html%3Ffailure%3Dtrue%26label%3DApache&data=02%7C01%7Caharui%40adobe.com%7C273ce1c1602c4009d2c708d737d74434%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039270013535645&sdata=h4q30uwXiXETcKWuqs%2B4znSV0FyaPHWm0zlXwidMnIc%3D&reserved=0
 Flex SDK
 
4.16.1&version=4.16.1&os=mac&installerversion=3.3.2&info=&info=Flash%20SDK%20download%20failed
 
 ~ Jeff
 
 On 8/21/19 23:33, Alex Harui wrote:

 > Try it again.  The checksums did change so I updated them.
 >
 > -Alex
 >
 > On 8/21/19, 7:23 PM, "Velocedge"  wrote:
 >
 >  I am getting a similar error on Windows:
 >
 >  Validating download:
 >  
D:\Software\Flex\SDK\latest/frameworks/libs/player/32.0/playerglobal.swc
 >  Flash SDK download failed
 >  Installation aborted:
 >  
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflex.apache.org%2Ftrack-installer.html%3Ffailure%3Dtrue%26label%3DApache&data=02%7C01%7Caharui%40adobe.com%7C273ce1c1602c4009d2c708d737d74434%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039270013535645&sdata=h4q30uwXiXETcKWuqs%2B4znSV0FyaPHWm0zlXwidMnIc%3D&reserved=0
 Flex
 >  SDK
 >  
4.16.1&version=4.16.1&os=windows&installerversion=3.3.2&info=&info=Flash%20SDK%20download%20failed
 >
 >  Is this just a checksum issue?  It's been a month since John posted 
his
 >  issue.  Is there something I can to do help?
 >
 >
 >
 >  --
 >  Sent from: 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-users.246.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C273ce1c1602c4009d2c708d737d74434%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637039270013535645&sdata=jUlp55v09uA%2Bb20Dm%2BFd%2F3wNoAcxtCYAPv%2BvPTR8Vhs%3D&reserved=0
 >
 >