Flash Forms for Smarties

This post shows how to whip up a form-based application in flash. It’s written for programmers, not for designers: the goal is to get the flash form layout work done as quickly and painlessly as possible.

In my example, I’ve tried to push as much programming logic as possible out of the binary fla file and into externalized actionscript files. Why? Well, if an entire application is in one file, it’s obviously tough for two people to work on it at the same time. Also, if it’s in binary form, it’s impossible to track changes. For example, if testing reveals that version 189 of your software is broken, your boss will want to know what the heck changed between version 188 and 189. Comparing text files is easy (and is supported by any decent source control system), while there’s no easy way to compare binary files.
The first step is to pay the piper: make sure you have Flash MX 2004 Pro. This tutorial doesn’t work with the non-pro version (doesn’t that suck?). Macromedia figures that developers working on web applications have a bigger budget that designers working on animations, so they only provide the Forms IDE with the Pro version. If this pisses you off, be glad you�re not developing enterprise software. Macromedia charges $11,000(!) for a 2-CPU license of FLEX, their XML-to-Flash compiler (they claim it’s much more than a compiler: most folks don’t seem to buy the arguement and want to keep macromedia software off their server if possible) that is targeted at the enterprise market. There’s a trial version of Flash MX 2004 Pro available on the Macromedia website, so try before you buy.
Start up Flash, and select “Create New Flash Form Application” from the middle splash screen that comes up. You’ll be brought to an interface that looks like this
The sections in the UI that we’ll be using are circled in the image above. The forms tree in the left panel is how you navigate from form to form and add new forms. The stage, dead center, is where you design a given form. Components from the Component toolkit on the right can be dragged onto the stage to add them to a given form. Actionscript code can be attached to a given component in the Actions screen on the bottom. And the Properties panel at the very bottom is a way of setting values in particular components.
We’re going to make a simple two-form web application. Add a second form directly under the first form, using the forms tree.
Now select the application using the forms tree. Then drag a Window from the Components area (middle right) onto the stage. This window will appear in every one of your forms. Resize it by adjusting the W and H values in the Properties area.
Now we’ll add some form widgets. Select form 1 using the forms tree. Now drag a button from the Components area (middle right) onto Form 1. Do something similar for form 2.
One weird thing about the form designer is that all forms display on the stage. So if you add a widget to form 1, by default it will appear in form 2 in the IDE as well! I’m not sure when this behavior would be useful. Anyway, to fix this, right click on each form in the tree view, and select “hide screen” from the drop-down menu. This only affects display in the IDE: it won�t affect your program at all.
Likewise, by default all forms will display on top of each other at run time. This is probably not what you as a form designer had in mind. The fix for this is to make every form except your first form initially invisible. In the “Properties” section (bottom of the screen) set “visible” to false for Form 2.
Now we need to hook the form up to some logic. The evil way that you do this is to click on a component (for example, the button in Form 1). Then go to the “Actions” screen below the stage and write your event handling code there. For example, to make something happen in response to a button click, write

on (click) {
//stuff happens

There’s better ways to make stuff happen, though, so if you wait till next week you can ignore that action handling code.
For another take on forms-based flash development, check out this tutorial from the macromedia web site.
Next time I’ll hook the form up to a rudimentry controller object. After that we’ll be on familiar developer turf, and we then we can start to look at design patterns for doing this kind of stuff.