Flex Controlling Flash


This article focuses on controlling applications written Flash Player 8 and below that are loaded into Flex at runtime. If you want to read up on the various ways of doing this, I’ve written in the past how to control Flash Player 8SWF’s in Flash Player 9’s new AVM. This article specifically will talk about using Flash Player 8 content in a Flex 2 environment.

Before you read further, I strongly suggest you beg those in charge to allow you to re-write the AS2 content in AS3 (Flex 2 or Flash CS3). If that fails, keep reading.

Use Cases

Here are some common use cases where one would want to load Flash content into Flex content:

1. You have some existing Flash content that was previously written for a Flash Player before 9 (8, 7, or 6). This content could be a fully functioning application that has already proven itself by working successfully for awhile. Therefore, you’d like load it in atruntime and let it do it’s thing. There is no time, budget, and/or resources to re-write the content in AS3. An example would be a video player written for Flash Player 8/7/6 customers (those who don’t have 9).

2. You have some content that was created by another company or 3rd party tool that you want to integrate and possibly control. This could be SWF’s generated by Captivate, Connect, Swish, or perhaps even older versions of Flash. There technically are no “source files” so you couldn’t necessarily re-write the content, or said content just couldn’t be created in Flex in the first place.

3. You’re a Flex Developer and have no intentions of learning Flash. You’ve been ordered to load SWF’s that are not AS3 and control them.

4. Like #3, except you can’t find any Flash Developer contractors that are available. Imagine that.

For the record, all 3 are valiant efforts fraught with peril. Knowing this, you can re-attempt my advice to plead with management to abandon the course in folly, or grit yer teeth and git-r-done. I won’t re-iterate the problems here, you can read that in the above link. I will, however, give a quick refresher on what you can and can’t do.

First, none of the above scenarios allow embedding. If you do not have the source FLA created in Flash, with a valid copy of the Flash authoring tool (MX, MX 2004, 8, or CS3), you have no choice but to load this stuff at runtime. If you DID have a copy, you could embed it. Embedding AS2 SWF’s, however, removes all of your code. Thus, embedding AS2 applications won’t work. You don’t have these problems with AS3.

Second, loading AS2 / AS1 content at runtime creates a separate, special security sandbox for the SWF that’s being loaded. The DisplayObject is called AVM1Movie, and he’s an iron-clad, impenetrable black box. There is physically no way to breech it via ActionScript 3 to talk to it. You can, however, useliasons over / under the wall via ExternalInterface or LocalConnection. ExternalInterface sucks because it uses JavaScript. Every project I’ve ever done that incorporated JavaScript as a necessity added 1 more level of complexity, extended the debugging time in the project, and overall made it more challenging to make progress. Thus, while theAVM’s may be different versions, at least we’re coding in a semblance of the same language and runtime… well, more than JavaScript anyway. AS1 and he may be similar , but at least AS1 works the same in all browsers. You already have enough challenging things to worry about now that you are down this dangerous path; you don’t need another headache.

Third, your AS3 content cannot immediately “get rid of” AS2 / AS1 content in this AVM1Movie thing. Garbage Collection will get it when it feels like it. In the AS2 / AS1 AVM, removeMovieClip for the win! It works immediately, and while the actual RAM of the used variables may not go away, all media stops (sounds, video, animation) as opposed to AS3 where you have to be explicit to do so, not just remove it from theDisplayList.

Solution: A proxy SWF, aka proxy.swf, aka, a Flex liaison to AVM1 content.

Why a Proxy SWF

Since Flex 2 content (Flash Player 9, AS3 AVM+ SWF’s) cannot tell AVM1 SWF’s what to do, they use a guy on the inside, a proxy.swf, to act as agents for them in that world. The proxy.swf executes the orders that Flex issues, and these orders are communicated via LocalConnection.

That downside is, you still need to code this proxy.swf in AS2 or AS1 and compile it for at least the Flash Player 8 or below. You don’t necessarily need Flash to do this. You could use MTASC, PHP’s Ming, or JGenerator (I think what Lazslo uses?). I haven’t gotten this to work myself, but you could also possibly use the Flex 2 SDK’s mxmlc with the “as3” compiler option set to false, and the “es” option set to true. This should generate a Flash Player 9 SWF that uses the old AVM (so… technically AS2 like code that’s compiled to AS1 bytecode using a Flash Player 9 compiler).

…or, you could use my generic compiled example, and hope for the best.

If you want to do it right (keeping in mind “right” here means not-so-right since we shouldn’t be using older SWF content anyway), you typically tailor a proxy.swf for the particular content you are loading. For example, if you are loading Captivate SWF’s, you build a proxy SWF that can:

1. load in Captivate content
2. control Captivate content by their *hidden API
3. unload Captivate content

* For more info on hidden API, go here, scroll to the bottom and download the big ole PDF, search for “rdinfoFrameCount” which should take you to the “Controlling Adobe Captivate projects with variables” section.

This, as opposed to just my generic proxy that just accepts methods as strings and runs them much like JavaScript’s eval. That way, you can expose a loose API. You can’t share AS3 and AS2 interfaces, but we’re already past the point of IDE help here, so you’re really doing faith based coding at this point. Anyone whose ever used a dynamic language (as opposed to strict typing) shouldn’t have a problem with this. If you don’t code the proxySWF specifically for the content you are loading, it’s harder to debug, and basically really hard to identify which remote method invocations are failing.

I’ve provided 2 examples at the bottom of this article. One is my generic “I’ll run what you send me” one and the other is one built specifically to control the Flash 8 Video Player. While the generic can be something you can build upon to support your content, I highly recommend you follow how the video player one is built and build the proxy.swf specifically control a specific SWF.

How It Works

They both work the same way.

1. Flex SWFLoader loads an AVM1 proxy.swf
2. proxy.swf loads the content it’s supposed to use via loadMovie / MovieClipLoader
3. once the proxy.swf has loaded it’s content, it let’s Flex know
4. at this point, Flex can now tell the proxy.swf to do things with the content it’s loaded

These can sometimes breakdown. LocalConnections are by their very nature asynchronous. While you can create an instance immediately, that doesn’t mean it’s immediately available for use. For example, the AVM1 version of LocalConnection gives you a Boolean so you know if the send actually worked. If you get a true, it doesn’t mean it actually sent, just that the send operation itself “worked”. Amazingly f’ing useless. Send again? Hell… WHY NOT!?!

The AS3 version is different. You can get a few different types of exceptions from sending messages, such as ArgumentErrors and AsyncErrors. While the docs claim that your syntax can be correct, and it could be your request is just bigger than 40k, this is a crock. Even simple strings can just fail, and then magically work later. In short, LocalConnection is flaky; you’re code should compensate. If you need ensured communication, use ExternalInterface. That, however, has it’s own can of worms.

You do not have to use a SWFLoader. You could just a Loader, but since Flex is UIComponent based, SWFLoader is UIComponent based, so there you go.

The proxy examples I have both use MovieClipLoader. While you could simply use loadMovie, MovieClipLoader gives you more events to understand what’s happening with your loaded content. You don’t have to write polling code yourself; instead, you have dependable events that fire. The only one you really care about is onLoadInit. When that fires, whatever SWF you are loading can now be accessed by code in an ensured fashion. This is why you wait for that to fire as opposed to onLoadComplete.


All of this communication between Flash & Flex is done via 4 LocalConnections; 2 in Flex, 2 in Flash. LocalConnections are only 1 way. Meaning, you can only send messages or receive messages; not both. I typically use the “in_lc” and “out_lc” naming convention; feel free to make up your own. The Flex out_lc talks to the Flash in_lc. Vice versa, the Flash out_lc talks the Flex in_lc. The only thing uber confusing is that in Flex, the names are reversed. Since LocalConnections connect on a “connection name”, these 2 names need to be the same in Flash & Flex. So, in Flash I have:

LC_IN_NAME = “_JXLFlashProxy_IN”;
LC_OUT_NAME = “_JXLFlashProxy_OUT”;

And in Flex, I’ll have the same thing for values, but different things for the names; just to help easy the insanity.

public static const FLASH_LC_IN_NAME:String = “_JXLFlashProxy_IN”;
public static const FLASH_LC_OUT_NAME:String = “_JXLFlashProxy_OUT”;

The only difference is in Flex, you use the OUT name for your Flex “in” connection. Since Flash is sending messages out on the OUT connection, Flex needs its IN connection listening to the “Flash OUT” connection name. The reverse holds true for Flex sending messages. He’ll send them on Flash’s IN connection name.

To reiterate, these messages are asynchronous. They don’t arrive immediately, and you cannot return values. You can treat it like events, where the LocalConnection in Flash can send a message back to Flex with data, but unlike events, you can’t depend on this; some messages just don’t make it.

Dynamic Flash

If you are not familiar with Flash, you’ll notice that both AVM1 examples just dig right into the SWF they are loading. This is because there is no runtime strong-typing in pre-Flash Player 9. For example, if you look at the video_player2.fla, you’ll notice some methods on the main timeline. Flex asks the proxy.swf to call those methods since he can’t. Like a kingpin asking a thug to get his hands dirty. I can access those methods as if they were public class methods… even dynamically by concatenating strings together in Flash Player 8 and below. This is where a proxy.swf shines in that since it’s made in dynamic Flash land, it can play by dynamic Flash rules. This is important because sometimes you’ll be loading SWF’s that you don’t have code control over, and need to jury rig them to do things they weren’t originally intended to do.

Keep in mind a proxy.swf can do more than just dynamically call methods and set properties on a load SWF application. It can also affect the nature of that application. Since you are still in a prototype based language, an object’s prototype property is writable. Thus, even if you don’t have the source, and don’t feel like using aSWF decompiler to get some form of source, you can overwrite prototype objects that you introspect to force the SWF to do things you need.

…you know, in writing all of that, I’d much rather use a proxy.swf with ExternalInterface. As much as I hate JavaScript, it was pretty easy to break LocalConnection. Maybe next weekend…

Source Code

Video Player Flex Example – Example | View Source | ZIP

Generic Flex Example – Example | View Source | ZIP

Captivate Player 1.2

Works with Captivate 2. Additionally, now supports skin.swf’s. Basically, you can choose a skin that your demo / movie uses, and Captivate 2 will generate a skin.swf. You point your playlist to those instead of your regular SWF’s. The CaptivatePlayer can now read them.

CaptivatePlayer is a SWF that plays multiple Captivate movies in succession. Since it’s best to create a bunch of 30 frame or less Captivate demo’s, you’ll typically end up with a bunch of them after a project. The CaptivatePlayer makes it easier to easily play those on the web. You just input their names into the XML playslist file, and upload with the CaptivatePlayer.swf.

Captivate Player 1.2 – Download

CaptivatePlayer v1.1

*** Updated to 1.2 ***

Updated my CaptivatePlayer to 1.1. New features:

  • added continous playback. Defaults to true so that if a movie finishes, the next one plays automatically without the user having to click.
  • added looping playback. Defaults to false, but if set to true, when the last movie is done, it’ll play the first one again. (for those with Kiosk needs)

I think I squashed a volume bug as well, but not sure. Additionally, I removed the flashvar settings in the default index.html file I provide; people were getting confused, and rightly so, about having the XML file and the HTML both setting different values. Now, just the XML configures the player.

The nested-menus, localization, and splash screen features are going to take awhile. I tried doing nested-menus, but my first attempt met with failure. I’ll get them in eventually in a future release, it’s just that the need for continous playback was constantly asked for so I figured I’d hurry up and release this version.

CaptivatePlayer v1.1 – Article | Docs | v1.1 ZIP

CaptivatePlayer Article & Upcoming Features

Macromedia graciously gave me the opportunity to write an article about my CaptivatePlayer, now up on DevNet, which is used to help Captivate users easily deploy their content to the web.

I’ve received feedback from a variety of Captivate users asking for specific features. That said, when things calm down towards the end of June, I can hopefully add these 2 requested features to it.

  • Global Navigation vs. the per demonstration navigation that Captivate generates currently. Something akin to a DVD player’s chapter controls so you can jump to other demonstrations.
  • Ability to have the presentation automatically play the next demonstration, and have this ability be controllable through the XML and through the interface.

CaptivatePlayer DevNet Article

Thanks, Macromedia!