ActionScript for Designers, Part 2

If you're reading this now, you either 1) bought into the whole "you should really be using ActionScript even though you're a designer" schpiel I outlined in our last installment, or 2) are here as a result of some sort of freak accident. Either way, today we're going to embark on the second leg of our journey into the strange and wonderful world of ActionScript, this time focusing on object targeting by examining how Flash keeps track of stuff behind the scenes.

First thing's first: what in God's green name (as a friend of mine once misspoke) do these target thingees have to do with learning ActionScript? Well, if you've tried to get going with ActionScript before, your initial stumbling out of the gate may have had a lot to do with the the huge potential for confusion in figuring out where things are in your average, everyday Flash movie. I know my first furtive forays into Flash scripting were fraught with frustration (and how's that for alliteration, huh?), so taking the time to figure out how Flash is internally keeping track of everything and how to control the process for the purposes of writing working ActionScript was a huge step for me. In a nutshell, learning Flash's targeting system will help you accomplish the two following things:

1. You'll be able to use ActionScript to control (or just observe) the most far-flung reaches of your Flash movie from anywhere else in the movie.
2. Eventually, you'll end up organizing your movies better, so you'll become even more efficient when using Flash.

Sounds good, right? It is. So, to quote the last words spoken on the final episode of a show that I already dearly miss, "let's go to work."

Order from chaos

The first thing we have to do is run through Flash's idea of symbols a bit. Why? Because only certain symbol types can become traceable for the purposes of writing ActionScript. I'm assuming that you've all used symbols by now, whether you're aware of it or not. You know those seemingly random "Tween 1" and "Tween 2" symbols that show up in your Library sometimes (fig. 1)? Those symbols aren't so random. Those appear if you've tried to animate a "raw" object without converting it to a symbol first, and those provide the first clue to what Flash is doing behind the scenes.

Figure 1: Auto-generated Tween symbols—the bane of many an anal-retentive Flash designer's existence.

Flash needs to make objects into symbols in order to be able to animate them, so it's doing the work for you when you see all those auto-generated Tween symbols appear in the Library. Just as Flash needs to "formalize" the objects in your movie to make them ready to animate, by extension, making symbols is the first step you need to take in order to make your Flash objects ActionScript ready. Making symbols yourself (as opposed to Flash doing it for you when you animate) is something you need to be really proactive about, because I'm relatively sure that it's easier to hunt down a particular symbol in a library full of (potentially) thousands of 'em if you've named it yourself and already know what you're looking for. Anyway, when you select an object in the Timeline and press F8, which is the handy-dandy keyboard shortcut to make a selected object a symbol, you get the options shown in Figure 2:

Figure 2

Ignoring the "Advanced" button until a little down the road, you can choose to make your Symbol either a Movie Clip, Button, or Graphic. What's the difference? Well, there are those who may tell you to not bother with anything other than Movie Clips and maybe the occasional Button for whatever you're doing, but I disagree. I still use Graphics as an important organizational tool (despite their bottom-of-the-list ranking in the Convert to Symbol panel), and explaining the difference between the three may help show why.

Movie Clips are just that: miniature Flash movie clips that live, self-contained, inside of your host Flash movie. They've got layers, independent timelines, the works. And most importantly for our purposes, they can be addressed via ActionScript (whether you name them or not). Now, a Movie Clip's status as an entire mini-ecosystem of sorts is a primary cause for targeting confusion, but we'll address that a little later on in this piece.

Buttons are specialized Movie Clips that have only four frames available to you (fig. 3), but the four that are there are just right for standard buttons (imagine that). You've got various states (up, over, down and hit) that let you define how the button will look in each stage of user interaction.

Figure 3: Even though you get these freaky frames in a Button, it's really just a specialized Movie Clip.

Finally, Graphics are the red-headed stepchildren in Flash, because while you can layer objects in them, and technically animate within them using the timeline as in a Movie Clip, Graphics only let you display a single frame when placed on the stage. Plus, they don't really "exist" as far as ActionScript is concerned, since only Buttons and Movie Clips can be named/addressed. So why use them?

Well, as I already mentioned, I still use Graphics extensively for organizational purposes. Any asset that will start "life" as a still image (either bitmap- or vector-based) gets put into a Graphic symbol with a _g suffix (while Movie Clips get _mc suffixes, and buttons are tagged with a _b). For example, there are many reasons to have a basic square in your movies, since they can be brought into many other symbols and transformed or tinted or whatever. So I'll usually create a 50x50 black square, convert it into a symbol, and call it square_g. Using the full range of symbols available to you really helps out when sifting through the library, as you have visual cues like icons and the suffixes to help you work things through. Plus, you can always alter the behavior of a Graphic symbol to behave like a Movie Clip (fig. 4), or even convert it to a Movie Clip in the Library, so symbols that start out as a Graphic need not stay that way.

Figure 4: Swap 'em on the fly. Any symbol instance can be converted to another type, which often comes in handy.

Trust me, all this is related to ActionScript. The bottom line is that only Buttons and Movie Clips are relevant as far as scripting is concerned, but that doesn't mean Graphics don't have anything to offer, so keep that in mind. Now that we've got the differences down, let's get to how Flash deals with the various types of symbols.

Behind the scenes

In this section, I'm going to introduce you to a panel in Flash which, if you've been blissfully unaware of its existence up until now, will become your new best friend. Output panel, meet the readers. Readers, meet the Output panel (fig. 5).

Figure 5

For those of you coming over from Director, the Output panel is akin to Director's Message window. For everyone else, it's like this: the Output panel gives you feedback on all kinds of things happening behind the green curtain in Flash, from triggers you write yourself to lists of all current variables in a Flash movie to alerting you to any errors you may have inadvertently made in your scripts. It's time for you and the Output panel to become acquainted at this point because it's going to help me illustrate what's going on when you place symbols into your movie. First, I'm going to create a new movie in Flash (incidentally, I'm using Flash MX 2004 Professional, but everything discussed should do just fine on MX 2004 Standard or even MX 2002 as well). Specific settings such as height, width, and frame rate aren't important at this stage, but for the record, my movie is 400 pixles wide by 300 pixels high and running at 60 frames per second. Also, in the Publish Settings Panel (File:Publish Settings...), I've deselected all formats on the Formats tab except .swf, and in the corresponding Flash format tab I've set the Version to Flash 6 just to prove I wasn't totally full of it when I said good ol' Flash MX was OK to use (fig. 6).

Figure 6: See? Flash Player 6 is perfectly acceptable for everything we'll be doing in this series.

Now that we've got some of the housekeeping out of the way, I'm going to use the Circle tool to draw a fairly simple shape on the stage (fig. 7).

Figure 7: Oohhh! Purty! And a perfect example of my scary artistic talent.

Easy enough, right? Now, without doing anything else, I'm going to test the movie, such as it is (Control:Test Movie). Once the test movie is built, it'll be displayed in all of its exciting glory in a window that looks remarkably like the stage I just left behind. Obviously, we'll need a little more info here, so I'm going to turn to a couple of Flash's built-in debugging tools: List Objects and List Variables, both of which are not-so-surprisingly located in the Debug menu that appears while you are testing your movies. If I select Debug:List Objects, I get the following:

Level #0: Frame=1
  Shape:

Hmm...not much happening here. Guess I'll take a look at Debug:List Variables while I'm at it:

Level #0:
Variable _level0.$version = "MAC 7,0,19,0"

OK, so that's a bit more, but there's still not a lot happening under the covers. So what have I learned so far? Well, I don't even have to look at the movie to know a little about it, which is what the Debug tools are for. And according to them, I've got a shape in Frame 1, there's something called Level #0 at work (which I'll get into later), and I'm viewing the movie in version 7.0.19.0 of the Macintosh Flash player (which is also a handy tidbit, but we'll have to come back to that too). I also got reinforcement of what I was trying to say in the first part of this article: that unless you convert a shape into a symbol, Flash is pretty much going to ignore it. So, I'm going to try and get some more usefulness out of my simple shape by converting it into a symbol, which I'll do by selecting the shape on the stage and pressing F8. Just for kicks, I'm going to make it a Graphic, name it purplecircle_g, and then click OK. I'll then have a single Graphic symbol in my Library (fig. 8), and, more importantly, a Graphic symbol on the stage (fig. 9).

Figure 8: I got me a Graphic in the Library.

Figure 9: A Property Inspector view of an instance of my Graphic on the stage.

Now, I'll test my movie once more (again, Control:Test Movie) and see if that made any difference in what the List Objects and List Variables tell me. Provided I actually knew what I was talking about before when I discussed the difference in Flash's symbol types, which I sincerely hope is the case, making the shape into a Graphic won't yield any change. Debug:List Objects shows:

Level #0: Frame=1
  Shape:

Look familiar? I'll try Debug:List Variables:

Level #0:
Variable _level0.$version = "MAC 7,0,19,0"

So, as it turns out, Graphics really aren't much better than "raw" shapes in terms of making their presence known behind the scenes. But, again, they're a good organizational tool, especially in terms of keeping file size down by instancing common shapes as much as possible. Plus, you can animate Graphics without Flash making all of those random Tween symbols in the Library. However, I'm interested in a little more at the moment, so I'll do a quickee-presto-change-o on the instance of my purplecircle_g Graphic to see if things start to clear up a bit.

Now, remember earlier when I mentioned that items originally saved as one symbol type don't have to spend life trapped that way? Well, I suspect a quick trip to the Properties panel might open up a whole new world to me, seeing as how I just got through pontificating about how some symbol types matter for ActionScript and others don't. So, I'm going to select my purplecircle_g Graphic on the stage, head over to the Properties panel, and change the symbol type from Graphic to Movie Clip (refer back to Figure 4 if you need a visual). A quick note: you can also change the symbol type in the Library (fig. 10), although doing so won't affect instances of that symbol that already exist on the stage. New instances that you drag over will inherit the behavior type you've selected by default, however.

Figure 10: Symbol types can be changed here in the Library as well.

So now that I have my circle behaving like a Movie Clip instead of a Graphic, I'm going to yet again test my movie and check what's happening with my debug tools. Debug:List Objects now serves up:

Level #0: Frame=1
  Movie Clip: Frame=1 Target="_level0.instance1"
    Shape:

And Debug:List Variables now gives me:

Level #0:
Variable _level0.$version = "MAC 7,0,19,0"
Movie Clip: Target="_level0.instance1"

Folks, I'm in business. To paraphrase Navin Johnson, my symbol is somebody! Instead of showing up as just a "Shape," Flash is actually assigning it a target (level0.instance1), which is super-important in the world o' ActionScript. Now I can, through ActionScript, do pretty much anything I want to good ol' instance1, from setting visual stuff (like height and width) to stashing variables in it to telling it to trigger embedded ActionScript to control something else (all of which we will eventually get to). But as far as behind-the-scenes processes go in Flash, targeting is the bread and butter. And, for the record, had I selected Button instead of Movie Clip, I would have seen similar results, as the Button type is targetable as well.

Of course, life would become quite difficult once there are several such instances in your movie, so referring to things as instance1 or instance2 (and so on) could get a tad confusing, especially if Flash is in charge of assigning the names all willy-nilly and stuff (like it does with those oh-so-helpful Tween symbols it likes to conjure up). But there is a simpler way—naming. If you've got a symbol defined as either a Button or a Movie Clip on the stage, the Property Inspector gives you a handy-dandy little Instance Name field (fig. 11).

Figure 11: Name me. Please.

Fill something in there, and you don't have to worry about what Flash might or might not name your various instances. So, in my case, I'm going to give my symbol a name: purplecircle. Inventive, no? A quick Test Movie command later, and my List Objects and List Variables selections now yield (respectively):

Level #0: Frame=1
  Movie Clip: Frame=1 Target="_level0.purplecircle"
    Shape:

Level #0:
Variable _level0.$version = "MAC 7,0,19,0"
Movie Clip: Target="_level0.purplecircle"

Needless to say (translation: I'm going to say it anyway), it behooves you to name your instances. But what to name things? My rule of thumb, as far as naming instances goes, is to stick to the rules for how you would name files on a web site:

1. Keep your names relatively short. Not "8.3" (DOS-style) short, but concise.
2. Don't use spaces or special characters—stick to alphanumerics. Dashes and underscores are generally OK too.
3. In Flash MX, case doesn't matter (e.g., if you name your instance MyInstance, you can refer to it later as myinstance). In MX 2004, ActionScript is, by default, case-sensitive, so proceed with caution and pay attention to your case (MyInstance and myinstance wouldn't reference the same instance, to continue the earlier example).
4. You can't use an instance name that's the same as something you would use in ActionScript. For example, _height is reserved for setting the Height property in ActionScript, so you can't call an instance _height.

We've taken kind of the scenic route to get to where we were originally headed, but we're finally here. Woo hoo! So, without further ado...

And now, a word or two on targeting

To sum up: Buttons and Movie Clips matter as far as ActionScript is concerned, and be sure to name your instances. It's kind of hard to believe that it took so many words to say just that, but getting there is half the fun, no? Anyway, let's take all that we just learned and try to channel it into what is hopefully a simple explanation of targeting.

To expand upon my earlier comparison, imagine your Flash movie as a Web site (which, for our purposes, we'll call flash.com), and all the stuff in your Flash movie as the various files strewn about the site. Each individual item on flash.com has some sort of relationship not only to the overall site, but to each other as well, and (as Web designers already know) each item can be located through either relative or absolute linking. So, for example, let's say Flash.com is like a lot of other sites, in that it keeps its images in a dedicated "images" directory on the root of the site (e.g., http://www.flash.com/images/). In that images directory sits a JPEG file, which we'll call banner.jpg (and therefore making its URL http://www.flash.com/images/banner.jpg). Now, let's assume there's a page on the site, buried several levels deep, that needs to display the banner image (let's call the specific URL in this case http://www.flash.com/html/stuff/morestuff/pageinquestion.html). If you were to use absolute linking, you would place the entire URL to the image file to the HTML page in question, http-colon-slash-slash and all. This works, but as designers will attest, it's not real portable. If you wanted to call the image using relative linking, your code from the html page would look something like this: ../../../../images/banner.jpg. Those several "../" instances are bumping the focus up one level, so to get back to where the images directory is from where the HTML page in question is, you have to go up four levels and then start drilling back down. This is much better in terms of moving the site around, but if you have page templates with common code the "theory of relativity" flies out the window, since not everything is in the same directory. There's a third option I've used for a while, which, for lack of a better term, I've been calling "absolute relative" linking. It works exactly the same way as absolute linking, except you chop off the first part of the URL (e.g., http://www.flash.com/images/banner.jpg becomes simply /images/banner.jpg). The leading slash in absolute relative linking simply means, for all intents and purposes, "start at the top."

In Flash, targeting works pretty similarly to linking on a Web site. Here are the salient points of differentiation, though:

• Instead of slashes, Flash uses dots.
• "True" absolute targeting only comes into play when you begin to load in external data sources, such as XML, TXT, FLV, JPG, MP3, etc. We'll certainly do some of this as the series goes on.
• Absolute targeting in Flash is really what I referred to as "absolute relative" linking for the Web, and instead of using a leading slash, it begins with _root.
• Relative targeting, instead of using "../" to go up a directory, uses _parent.
• There's yet another prefix you can use, this, which is another concept (and the list is growing) that we'll get into later.

OK, so what does all that mean? Let's do a quick bit of translation. As you'll recall, on flash.com we've got a banner image with the URL of http://www.flash.com/images/banner.jpg that you want to call from a HTML page with the URL of http://www.flash.com/html/stuff/morestuff/pageinquestion.html. In Flash, it's likely you'll be moving between instances of Movie Clips, so we'll say the banner image is actually a Movie Clip called banner, which is nested inside of another Movie Clip called images. You want to send some ActionScript to the images Movie Clip from another nested clip, clipinquestion, which is buried several layers deep inside a string of other clips. To target the banner clip from your clipinquestion using relative targeting, your path will look something like this:

_parent._parent._parent._parent.images.banner

If you were to use absolute targeting, your path would look like this:

_root.images.banner

Despite looking quite different from the Web equivalent, I'm hoping you see how similar they really are. In this case, and indeed, in many cases, it makes a lot of sense to use absolute targeting, just for portability's sake. When we get into writing functions in a later installment, the advantages of absolute targeting should become clear. But having relative targeting down is a bonus as well, because it's easy to create self-contained "module" clips that can function anywhere you drag them. So, for now, let's leave things at understanding how to construct a path in Flash, which will be the basis for a great many things we're going to do from here on out.

Next time we're going to start doing some actual work. You'll get acquainted with the Actions panel, I'll show you a GUI you can use for targeting (when things get hairy), and we'll actually create some honest-to-goodness, working code to start us on our way to ActionScript bliss. So, as the proverbial "they" sometimes say in my part of the world, see all y'all then!

Filed under: Tutorial on June 10th, 2004

^ Top of Page

Got Feedback? to send an email. I'll do my best to answer. Really.