Comments on: SWF9 to SWF8 Communication – EI not LC – Part 2 http://blog.tracethis.com/archives/2006/07/13/swf9-to-swf8-communication-ei-not-lc-part-2/ Flash, SWF Studio, and the world around me Sat, 07 Jan 2012 22:51:17 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Derek Vadneau http://blog.tracethis.com/archives/2006/07/13/swf9-to-swf8-communication-ei-not-lc-part-2/#comment-108 Derek Vadneau Thu, 27 Sep 2007 14:21:46 +0000 http://tracethis.com/?p=55#comment-108 @Paolo The communication in that case is limited by Flash Player security. You can get around this by setting the allowScriptAccess parameter to always. In my example I left the default of sameDomain. That should allow both SWFs to talk to JavaScript, and thus, each other. You might also need a crossdomain.xml file for the remote SWF. I haven't tested this yet. @Lawrence Thanks. Yes and no. ExternalInterface is available to the container. If you are building a VB, C++, C#, etc., application and embedding the Flash Player within, then your app can receive an event when the Flash Player is trying to communicate using ExternalInterface or FSCommand. FSCommand passes data out of the Flash Player as a string with no encoding. ExternalInterface passes data out in XML format, and expects data in to be formatted similarly. With EI you have to encode and decode the XML yourself. So, it is possible to have EI work in your own application outside of the browser. In fact you would have little parsing to do if all you wanted to do was have the container act as a local loop. For the standalone Flash Player it is not possible. EI isn't available from the standalone Flash Player. You will receive a runtime error if you try and execute using EI. There's a property on ExternalInterface (available in AS3) called available that you can use to distinguish whether or not this type of communication is allowed. Some notes on the different methods: LocalConnection would be the slowest and most limiting, imo. It has a 40KB data limit and tends to be slow and unreliable. It is asynchronous. However, it can be used to connect to another Flash Player instance, regardless of where that Flash Player is contained. It's limited by the fact that a connection is only between two instances. A third instance trying to communicate to one of the other two will fail. You also can't communicate (easily) with the container in this way. EI is not incredibly fast and does require you to encode/decode XML-safe data. It is, however, the only mechanism for getting data back into the AVM2 without using sockets. EI is synchronous, stopping AS execution until the container returns from FlashCall (the event). FSCommand is by far the fastest, since there is no encoding/decoding. But it is only one-way communication. FSCommand is asynchronous, since it is not executed to the container until all other ActionScript in the same frame has executed. Therefore the fastest data can be returned to Flash is in the next frame. @Paolo
The communication in that case is limited by Flash Player security. You can get around this by setting the allowScriptAccess parameter to always. In my example I left the default of sameDomain. That should allow both SWFs to talk to JavaScript, and thus, each other. You might also need a crossdomain.xml file for the remote SWF. I haven’t tested this yet.

@Lawrence
Thanks. Yes and no. ExternalInterface is available to the container. If you are building a VB, C++, C#, etc., application and embedding the Flash Player within, then your app can receive an event when the Flash Player is trying to communicate using ExternalInterface or FSCommand. FSCommand passes data out of the Flash Player as a string with no encoding. ExternalInterface passes data out in XML format, and expects data in to be formatted similarly. With EI you have to encode and decode the XML yourself.

So, it is possible to have EI work in your own application outside of the browser. In fact you would have little parsing to do if all you wanted to do was have the container act as a local loop.

For the standalone Flash Player it is not possible. EI isn’t available from the standalone Flash Player. You will receive a runtime error if you try and execute using EI. There’s a property on ExternalInterface (available in AS3) called available that you can use to distinguish whether or not this type of communication is allowed.

Some notes on the different methods:
LocalConnection would be the slowest and most limiting, imo. It has a 40KB data limit and tends to be slow and unreliable. It is asynchronous. However, it can be used to connect to another Flash Player instance, regardless of where that Flash Player is contained. It’s limited by the fact that a connection is only between two instances. A third instance trying to communicate to one of the other two will fail. You also can’t communicate (easily) with the container in this way.

EI is not incredibly fast and does require you to encode/decode XML-safe data. It is, however, the only mechanism for getting data back into the AVM2 without using sockets. EI is synchronous, stopping AS execution until the container returns from FlashCall (the event).

FSCommand is by far the fastest, since there is no encoding/decoding. But it is only one-way communication. FSCommand is asynchronous, since it is not executed to the container until all other ActionScript in the same frame has executed. Therefore the fastest data can be returned to Flash is in the next frame.

]]> By: lyau http://blog.tracethis.com/archives/2006/07/13/swf9-to-swf8-communication-ei-not-lc-part-2/#comment-107 lyau Thu, 27 Sep 2007 13:27:49 +0000 http://tracethis.com/?p=55#comment-107 Useful indeed! I'm curious if the ExternalInterface solution is applicable when the application is not running within an embedded flashplayer on a web page. LocalConnection works even if running in the standalone flash player or within an OCX component in a .NET application (I'm not sure about an AIR app). Great article. Lawrence Useful indeed! I’m curious if the ExternalInterface solution is applicable when the application is not running within an embedded flashplayer on a web page. LocalConnection works even if running in the standalone flash player or within an OCX component in a .NET application (I’m not sure about an AIR app).
Great article. Lawrence

]]> By: Paolo Bassino http://blog.tracethis.com/archives/2006/07/13/swf9-to-swf8-communication-ei-not-lc-part-2/#comment-105 Paolo Bassino Thu, 26 Oct 2006 16:05:05 +0000 http://tracethis.com/?p=55#comment-105 Thank you for these explanations, very useful... but... if the swf8 file is loaded from a different domain, it seems that the communication from swf9 to swf8 doesn't work anymore... any ideas? Thank you. Thank you for these explanations, very useful… but… if the swf8 file is loaded from a different domain, it seems that the communication from swf9 to swf8 doesn’t work anymore… any ideas?
Thank you.

]]>