By Marc Lee | Member
This column addresses media subjects for technical communicators. It discusses graphics, audio, animation, video, and interactive media as they relate to technical communication. Please send comments to marc@mlmultimedia.com.
In my column about Flash last year (Intercom November 2010), I described the basic Flash desktop: the timeline, stage, frames, and the playhead—which are the basic interface objects for creating Flash projects. In this article, I continue to explore Flash, this time adding the element of scripting. I hope some of you accept the challenge of Flash programming, get a trial license, and give Flash a try: it’s a tool truly without limitations for conveying your content and vision, if you have the interest to take the plunge.
Flash movies—really little “programs” once you start writing scripts—are great for learning games and simulations of the physical world. To get those effects, you’ll need to learn some programming, so let’s dive in.
Let’s first review what you can do in Flash without programming:
- Place an image or a drawn object on the stage.
- Animate the image or object; that is, enable it to move, change shape, or disappear completely.
- Synchronize sound, such as a voice track or a sound effect, with the animation.
- Place text on the stage and allow the text to change or move in sync with the other effects.
- Place and play a video inside your Flash piece.
Figure 1. Scripting Keyframe
Here are some things you can do in Flash that require some programming:
- Allow the user to interact with the animation, such as clicking on the image they prefer, typing text onto the stage, or controlling the sound track or video (rewind, pause).
- Connect the stage with an outside source, such as a different website, or with external assets, like a JPG photo or video submitted by a user.
- Allow the user to enter information, such as their contact information, into the Flash movie.
- Connect the content on the stage with external data such as an XML file or a database; for example, allowing the Flash movie to show test results that might change from day to day. This starts to expand the scope of what can be done, wouldn’t you say?
I can’t cover even the beginnings of the full scope of ActionScript programming in this article. There are many subjects such as ActionScript versions, syntax, expressions, classes, methods, events, global functions, and Flash components to learn about. If you’re really going to get started in Flash programming, you’ll have to either take a class in ActionScript or get one of the many ActionScript books available in the bookstores.
Figure 2. Flash Desktop with Actions Pane Selected
Instead, I’ll cover a subject that—surprisingly—is barely mentioned in the programming books, and one whose absence will cause you headaches until you figure out how to approach it, and that is how the ActionScript code integrates into the Flash development desktop.
Where Do I Put My Scripts?
Recalling last year’s article on Flash, you’ll remember the timeline and the concept of keyframes and layers.
In Figure 1, we show one keyframe in the timeline and one layer of that keyframe devoted to scripts, or as Flash calls them, “actions.” The “AS” label on that layer stands for ActionScript. There is nothing mandatory about naming the layer that, but it’s a good standard to follow. An important detail we’ll discuss later is that all the objects in the project—the slider, the thermometer, the vid screen, and the ActionScript—are in Frame 1. The little “a” shown in the top keyframe is Flash telling you that there are ActionScripts in that keyframe.
Let’s click on the “Actions Frame” tab and see what’s inside.
Scripting in Flash is just typing code into the Actions Frame, as shown in Figure 2. Because there is no practical limit to the number of keyframes in a Flash project, there can be many locations of script. Notice that there is just one keyframe with script in this project—shown twice in the tree-view in the left-hand pane as the name of the keyframe and as the currently selected keyframe. But both are Frame 1.
It’s highly recommended that you keep most or all of your script code in one keyframe. The scope of scripts in Flash is typically global throughout the whole project. That is, the actions are not specific to one keyframe or one layer; they apply to all keyframes and all layers equally. Therefore, in Flash it’s considered extremely bad form to spread your code out among many keyframes or many layers. The reason is that, when scripts get complex, it becomes extremely difficult to debug code that is spread all throughout your project.
Connecting Code to Stage Objects
Unless you connect your script to stage objects, your script will have no effect. Let’s say there is an image on the stage you would like to make clickable by the user. You will have to do three things: 1) create or import the image to the stage, 2) convert that object to an “instance” of a “symbol” (I’ll explain those terms in a minute), and 3) write some code that identifies the instance by name and does what is needed to make it clickable.
The way that is done in ActionScript is to create something called a symbol.
Figure 3 shows part of the dialog that appears when you select the object on the stage and select Convert to Symbol under Modify in the main tool bar. Flash offers three types of symbols (movie clips, buttons, and graphics). In the example shown, the symbol is a movie clip type. I’ve left the name of the movie clip as “Symbol 1” (the default), but you could and probably should change it to another name. By converting any graphic or image on the stage to a symbol, you are most of the way there to being able to address that image or object in script.
Figure 3. Convert to Symbol Dialog
Recall that in explaining Figure 1, I mentioned that the scripts and the stage objects are all in Frame 1. That’s an important detail. Because Flash plays frames in sequence, it’s essentially a bug in the code if you refer to an object in script whose frame has yet to appear. That detail must be precisely synchronized. And it’s something to keep in mind because debugging that sort of out-of-sync issue can be very time-consuming. You click on something and expect to see an action in response, yet … nothing. Every Flash programmer has been there. Always keeping things as simple as possible, perhaps consider using only one frame for everything on the main timeline (movie clips and buttons can have sub-timelines, but that’s something beyond the scope of this article). That way, you’ll never be out-of-sync in the script-frame-to-object-frame sense.
Figure 4. Instance Name
Once you have converted your object to a symbol—say, a movie clip—you still have one more step: the “instance name” (Figure 4).
By clicking on the newly created movie clip symbol on the stage and selecting the “properties” tab, you can see and edit information about the movie clip—notably here, its instance name. The instance name can have no spaces and a limited character set. The convention is to run terms together in the main body of the name and append the type of symbol after the name using an underscore. So a typical instance name would be something like “myThermometer_mc,” where the “_mc” stands for movie clip.
Now you’re finally ready to write a piece of script against your stage object.
For example, you could say:
Figure 5. ActionScript 2.0 example
Figure 5 shows the framework for a click event using ActionScript 2.0 syntax. ActionScript 3.0 is a fully OOP-based language that makes simple clickable objects much more complicated to code. (However, it has other virtues too detailed to get into here.)
Now You’re on Your Own
With that, you’ve got the basic structure of a Flash program incorporating ActionScript. From here on, the world of syntax, objects, components, functions, classes, and many more things will open up. It will take you a while to learn, but it’s worth it. The Flash Player is a powerful code engine capable of tearing through hundreds of lines of well-written code and reacting crisply to user commands. It’s all up to you to make it happen.
