Moving from Authorware to Flex

I started out as an Authorware developer, and one reason I am now doing Flex is that Adobe announced the End of Development of Authorware just over a year ago. I saw that Flex offered a lot of the advantages of Authorware--it does a great job of integrating various media into a cohesive whole and you can make an application that runs from the web or the desktop from approximately the same code.

Adobe's decision left many people scrambling to figure out where they would go, so Randy Nielsen from the Flex documentation team worked with a few Authorware developers to get a stub page up when Flex 3 was released so that Authorware developers could document what their experiences have been to help ease the process of making the migration for those who felt that Flex was the best Authorware replacement for them.

At long last, I managed to make some time to add my 2¢ worth to the document. So I'm happy to announce that the Moving to Flex from Authorware page at the Flex documentation wiki has been updated. There is one section that I wrote that for some reason isn't included, and I feel it may be useful to some people, so I'm posting it here:

Using Flex files inside Authorware
In large existing projects, it might not be feasible to migrate the entire project to Flex over night. One strategy is to create new functionality in Flex and embed that in Authorware. When Authorware finally is abandoned, the Flex functionality will still be useful.

Flex Side
Flex and Flash have an object, ExternalInterface, that allows them to communicate with whatever application contains the swf file. Normally, this is used in a swf embedded in the browser to communicate with javascript that is written in the HTML page.
At the moment that the swf loads, the child components of the swf don't yet exist, so any attempt to set any properties on them will cause an error, which will probably stop your Flex application from proceeding any further. So you should wait until everything is created before initiating communication with the container. This means that you should run a function on creationComplete that will use ExternalInterface to call out to the container and tell it that it is ready to receive data. This function should also set up the callback functions, which are the functions inside your Flex application that are accessible to the container.
The container should then respond by calling a function and providing data your Flex application needs as an argument. This can be a user name, lesson status, or XML that represents a menu. The function should perform whatever parsing is needed on the data and set object properties based on the data.
When the user interacts with the swf, it should again use ExternalInterface to tell the container what happened.
Once you have created your Flex file, you should make sure to export a release build by going to Project>Export Release Build. This file will be smaller and run more efficiently than the debug build that is built by default.

Authorware Side
The Authorware file will have a Shockwave Flash Object ActiveX control icon in it. The development machine should have Flash Player version (Randy, what's the minimum version of the Flash Player for Flex 3?) on it, and you'll need to make sure that the users have at least that version installed.
Next, you'll need a calculation icon that sets up the path to your swf file so that Authorware can find it. This will start the loading process, which will culminate in the creationComplete event.
Once the creationComplete event fires, the swf will generate an event that can be seen in Authorware by using ExternalInterface. To catch this event, you'll need to use an Event Response on an Interaction icon. The response should be set up to respond to the FlashCall event. This seems to work best as a perpetual response on an Interaction that is below the ActiveX Sprite on the flow line, but above the calculation that sets the path to the swf.
The information contained in the #request property of the EventLastMatched variable will be an XML formatted string, so you'll need to use an XML parser object to access its contents. The same event response will trigger every time the Flex Application calls ExternalInterface.call, so you'll need to look at the name of the root element to see what "function" the Flex file thinks it is calling and branch based on that.
In the branch that you set up for the initial call where the swf tells you it is started, you should respond by issuing a CallSprite command to the Flash ActiveX Sprite icon that calls a function in the swf with the data you want to see in Flex. Other branches should contain logic to respond to different calls the swf sends with ExternalInterface.

Download the example files.