Chapter 2. What s New in Flash MX

CONTENTS

Chapter 2. What's New in Flash MX

•  General Enhancements
•  Features for Programmers
•  Book Conventions and Expectations
•  Summary

This chapter would have been easier to write if I had called it "What's Not New in Flash MX." The Flash MX upgrade is huge! I can't cover everything that's new, of course, but this chapter covers the main highlights of Flash MX and provides a course outline for the rest of the book. That is, I'll cover as much as I can, but most topics will be introduced only, with references to upcoming chapters that cover them in full.

Although I don't recommend skipping any chapter (this book does follow a sequence), you certainly should read the last section in this chapter, "Book Conventions and Expectations." It discusses how to get the most out this book as well some tricks to help you learn programming.

In this chapter, you'll learn:

• The most significant product enhancements.

• How the programming language has been improved.

• How to use this book.

I've actually saved this chapter to write last. This way, I know which topics are covered, where they're covered, and how. If you like to know where you're headed, this chapter should be revealing. It turns out the first section, "General Enhancements," has little to do with scripting, so I've kept it brief. You can pick up some tips and ideas in this section. The second section, "Programming Enhancements," introduces topics that we'll revisit throughout the book. Let's start with a quick rundown of the "non-programming" enhancements.

General Enhancements

In my opinion, the "killer feature" of Flash MX isn't actually video; it's work-flow. Nearly every nook and cranny has some touch-up to usability. Small, subtle features are scattered around, but they result in improvements to productivity. In Flash 5, for example, when you select a fill color and then select an already filled shape, the Fill Color tool loses the color you selected. What if you want to use that color? That task is simple in Flash MX, which includes a ton of tiny such changes. I used to like to make fun of the peculiar quirks in Flash, but frankly, I'm running out of comedy material.

Video

Like I said, video might not be the "killer feature," but it's still pretty killer. You can import and compress videos of nearly any source data type by using Sorenson Spark (a compression technology built into Flash with matching decompression capabilities in the Macromedia Flash Player 6). Basically, this means that you can import video, set the best compression balance of filesize and quality, and then use the video as though it were any other Library symbol.

It's usually best to place your videos inside a Movie Clip. You can then mask the Movie Clip to reveal only parts of the video frame. Also, because videos are synchronized to their timeline (the way multiple-frame graphic symbols are), you can end up with long timelines.

Really, to get the most out of video in Flash, you need to understand the rules that apply to compression. Start with the best quality video footage as possible; when selecting compression options, consider the nature of your content; and realize the trade-offs between quality and filesize (such as high frame rates, which result in larger files). A third-party product is available, called Sorenson Squeeze, which, like Flash, uses Spark to compress videos. Sorenson Squeeze offers other better-quality compression settings and features, including batch processing (which compresses several files in sequence rather than individually).

Finally (and I really wish I could explore this topic fully), Macromedia has server products in development that through the Flash Player 6 will allow two-way communications, including voice, video, and shared data between multiple users. Now that might really be the "killer feature." (Alas, you won't hear any more about those products specifically in this book.)

Workspace

Even though the subtle features are what really enhance your productivity, the obvious changes in Flash's interface are what you notice first. Flash MX's entire screen is cleaner because panels are snapped into panes, where they can take up the most screen space without overlapping other panels. Even if you undock a panel to make It float, other panels docked with a floating panel will expand to fill the space efficiently. Ultimately, though, the panels are less cumbersome because there are fewer of them. Less clutter is a good thing.

The newly added Properties panel takes the place of 12 panels that have either been removed or replaced because the Properties panel contains so much information. Gone are the panels for Character, Paragraph, Text Options, Stroke, Fill, Instance, Effect, Frame, and Sound. How can the Properties panel replace all those panels? Simple: It changes to reflect the properties of whatever you have selected. I don't need to walk through how this works it's very intuitive. I'm sure you'll keep the Properties panel open most of the time.

I have only a few tips for the new panel design (including the Properties panel). Realize that some panels have expand/collapse arrows so some parts can be hidden from you. Also, be sure to play with all the organization options: the "gripper" area (to dock panels), the minimize/maximize arrow (in the panel's title), and the super-mini "window shade" mode (which appears when you double-click the title bar on a floating panel). You can also save panel layouts, like you could in Flash 5.

There are plenty of other interface changes. A really big one that is the timeline now has folder layers into which you can nest multiple layers. The cool thing here is that making a folder invisible or visible affects all the nested layers. Related to layers is the Distribute to Layers command under the Modify menu. When you combine that feature with the new way a block of text breaks into individual characters (the first time you select Modify, Break Apart), you can quickly make sophisticated animations.

Shared Libraries

If you thought shared libraries were half-baked in Flash 5, you really ought to give them another try. The entire feature has been overhauled, making it easier to understand and to use.

There are two confusingly similar features: runtime sharing and authortime sharing. Runtime sharing involves storing symbols in a source movie (that gets exported to an .swf), and then giving many other movies access to the media in that shared file. Shared libraries have worked this way since version 5. Now, however, you have a couple of extra options, including the decision of whether or not the shared item must download completely before the first frame appears (an old requirement that made the user sit through downloading all shared items even if the items weren't needed right away).

Authortime sharing is similar in that you have one source movie with shared symbols, but at the time a movie using the shared items gets exported, those items are copied into the user movie. This isn't quite as efficient because you have to re-export all user movies after you edit the shared item. There are no complex download issues, however.

Note

Authortime sharing is really quite useful and a vast improvement over Flash 5. All you do is create a symbol in one movie, save that movie, and then either copy and paste that symbol or drag it into a new movie. Then, in the new movie, you can select Properties for the duplicate symbol in the Library (from the options menu). In the "Advanced" section of the Properties dialog box, you should see that the Source section provides a way for you to automatically re-import (that is, "update") the symbol every time you publish or test the movie (see Figure 2.1). You'll find additional options to "link" to other symbols in other source .fla files. Just remember it's only linked while authoring; once you publish, all symbols are embedded as though you copied and pasted.

Figure 2.1. The new Advanced Symbol Properties dialog includes options for authortime sharing

Note

Another feature (that works regardless of the authortime sharing feature) is the way duplicate symbols are handled. Actually, because each symbol must have a unique name, you can't have duplicates. Now in Flash MX, however, when you paste a symbol that matches the name of one already in your movie, you're given the option to either replace or keep the original (just like what happens when you copy a same-named file into a folder on your computer). This is one of those small touches that makes Flash MX so much more usable than Flash 5.

The bottom line is that shared library items (and, for that matter, the new template feature) are worth learning because they will make you more productive.

Ready-Made Components

Components replace the old Smart Clip feature. The components that ship with Flash MX include interface widgets, such as buttons and drop-down menus. A second set has shipped (since Flash was released), and I suspect many more are to come. You'll learn how to make your own components in Chapter 15, "Components." One of my favorite new ones is "Tree," a hierarchical-view component that makes a folder-selection interface a snap (see Figure 2.2).

Figure 2.2. The Tree component (downloaded for free from Macromedia Exchange) helps you create graphical views of complex, nested data.

My natural tendency is to suggest that you try only to learn from the built-in components (as source files are available). However, because they're so well made and useful, I'd say to go ahead and use them in your projects. You can still snoop through the source files to see how they tick. I'd never criticize something that works and these work great. There are many additions to the ActionScript language, especially for making components. This means that not only will you see some cool components that others make, but you'll be able to make your own as well.

Flash Player Performance

The performance of the Flash Player has been improved in several ways. First, operations involving strings and XML data are much faster because all the code was re-written in a low-level language (whereas scripting languages are considered to be "high-level" like you're at a higher level than the computer). Anyway, there is always more than one way to solve a programming task. In past versions of Flash, you often could see a huge performance difference, depending on which solution you used. People would often test different solutions to see which was the fastest. Although you might still see a few milliseconds difference between the available options for some string operations, there are no longer extreme cases.

Another improvement is in the compressed size of your .swf files. Under the Flash tab in Publish Settings, you'll see an option for "Compress Movie" when you export as Flash Player 6. This applies compression to your scripts (but only the Flash Player version 6 can uncompress them). Movies with a ton of scripts export to much smaller .swfs.

Although Flash MX has a ton of other new features, I think all of these are interesting because they save you time. As you may or may not know, one of the ultimate ways to save time is to program solutions that would otherwise take a great deal of effort to create. That's really what this book is about, so let's take a tour of the features for programmers.

Features for Programmers

The vast majority of the new features in Flash MX are geared towards programmers (lucky us!). Not only are there countless additions to the programming language itself, the improvements to the interface make programming easier. Sure, creating a complex web site using components is a snap, but that's not what I mean when I say programming is easier. Complex programming is still complex, but the new features mean that you'll spend less time creating workarounds or fixing stupid mistakes. For example, you can now set the Actions panel preferences to any font, whereas before the font made a "0" look nearly the same as "()" and the font was so small that you couldn't tell the difference. There are a ton of things like this, but I'll try to stick to the biggies.

Revised Actions Panel

All scripting gets typed into the Actions panel. Anything that saves you time while editing scripts is a good thing. Even after you become a proficient programmer, it's likely that you won't be able to just type in some code and see it work. The process involves constant refining either to fix bugs or to add features. The last thing you need is stupid mistakes like typos and improper syntax. The features in the Actions panel should help reduce errors.

Code Hints and Auto Completion

Code hints and Auto Completion are probably my favorite features in Flash MX because they help you every time you script. As soon as you start to type a recognizable word from the ActionScript language, a tooltip appears with the proper syntax to guide you along (see Figure 2.3). Code hints are almost like quickly referencing the help files automatically while you type.

Figure 2.3. Code hints pop up as you type to guide you along.

Auto Completion is similar to code hints. A host of properties and methods are made for any given object type. (Don't worry if you don't recognize every vocabulary word in that last sentence; you'll learn them all soon enough.) For example, a Movie Clip instance has a gotoAndStop() method that causes a clip to jump to a particular frame. When you type "my_mc.", you'll see a list appear as soon as you type the period (see Figure 2.4). You just select the gotoAndStop method, and Flash automatically completes the code for you. (Actually, the code hint for gotoAndStop() appears to help you further.) To see this for yourself, select a frame in the timeline, open the Actions panel (F9), make sure the Actions panel is in Expert Mode (Ctrl+Shift+E), and then type my_mc. The list appears from which you can select gotoAndStop. All you have to do is to memorize the designated suffixes that Flash uses. (Movie Clip instances use the _mc suffix.) I'll be sure to use the default suffixes throughout the book as new object types are introduced but as you'll see next, you can change the "recommended" suffixes to whatever you prefer.

Figure 2.4. The Auto Completion feature provides a list of appropriate options once it can determine the context of your script.

Extensible Configuration

I think the easiest misconception about the Actions panel is that it represents the entire ActionScript language. In fact, the entire contents of the Actions panel are extensible. For example, if you want to change the suffix that triggers the Auto Completion for Movie Clip from _mc to _movie, you can edit an XML text file called "AsCodeHints.xml" that was installed on your computer when you installed Flash MX. You'll need to know how and where, of course (and I'll show that shortly).

You can customize more than just the Auto Completion rules. A bunch of other parts can be adjusted to fit your work-style. The Actions panel has a "toolbox" list on the left. Well, the folders, organization of those folders, and the contents of the folders can all be edited or added to. Code hints for any element, including things you add, can be edited. Finally, you can change the words that automatically change color as part of Flash's "Syntax Coloring" feature to whatever you want.

Without fully documenting every detail of how to make adjustments, let me start you in the right direction and give you a few pointers. First, the actual location for these configuration files varies based on operating system. Just look in the Configuration folder (adjacent to your installed version of Flash MX) to find the "Readme" file, which explains where to find the other Configuration folder. Anyway, once you find the right Configuration folder, there's a folder called ActionsPanel, inside of which you'll find several XML files these are the ones to edit. Naturally, you really should keep a backup of these files before you edit them, but Flash is smart enough to restore the default set if they are missing. (This is not true for the files inside the "Custom Actions" subfolder, which are created when you install new components so don't remove them.) To get an idea how you can change the Auto Completion feature, open the file AsCodeHints.xml using a text editor. Scroll to the end and you'll see several lines that all begin "<typeinfo" (see Figure 2.5). You should see the pattern matches that trigger Movie Clip methods (*_mc), arrays (*_array), and so on. You can change *_mc to read *_movie, if you like. Then, any time that you end a Movie Clip instance name with _movie, you'll see the automatic completion list appear (as soon as you type a period).

Figure 2.5 At the end of the AsCodeHints.xml file, you'll see all the default suffixes (where you can optionally edit them).

  <typeinfo pattern="*_mc" object="MovieClip" />    <typeinfo pattern="*_array" object="Array" />    <typeinfo pattern="*_str" object="String" />    <typeinfo pattern="*_btn" object="Button" />    <typeinfo pattern="*_txt" object="TextField" />    <typeinfo pattern="*_fmt" object="TextFormat" />    <typeinfo pattern="*_date" object="Date" />    <typeinfo pattern="*_sound" object="Sound" />    <typeinfo pattern="*_xml" object="XML" />    <typeinfo pattern="*_xmlsocket" object="XMLSocket" />    <typeinfo pattern="*_color" object="Color" />    <typeinfo pattern="*_level*" object="MovieClip" />    <typeinfo pattern="*_parent" object="MovieClip" />    <typeinfo pattern="*_root" object="MovieClip" />  </codehints>

Obviously, there are more details to the configuration files. For example, you can see that the "ActionsPanel.xml" file (in which you can change the contents of folders that appear in the Actions panel toolbox area) is a much more complex file. Generally, though, I've found that you can edit or supplement any of these files by modeling after what's already in the file. In the case of the ActionsPanel.xml file, you can copy an entire "folder" or a single "action" node, and then make edits to the properties name, tiptext,and text. However, if you create any new entries, remove the properties for helpid and quickkey so that your additions don't conflict with other elements. All of this makes more sense if you understand the XML data structure (which is covered in Chapter 16, "Interfacing with External Data"). To give you a practical example, the following is a line of text that I inserted between lines 783 and 784 of the ActionsPanel.xml file:

<string name="allowDomain" tiptext="Allows another domain to load this movie"  text="System.security.allowDomain()" version="6" />

All I did was to copy line 783, remove the references to helpid and quickkey, and then make a few edits. Now, whenever I begin by typing "System.", the Auto Completion dialog box appears, and I can even find allowDomain in the Actions panel under Objects, Movie, System. Basically, allowDomain is a feature in ActionScript that wasn't included in the Actions panel so I added it to mine. (By the way, you'll hear more about allowDomain later in this chapter, and in Chapter 7, "The Movie Clip Object," you'll see how it works.)

Presumably, Macromedia will fully document the format of these configuration files but they're not too difficult to deconstruct. Realize, too, that I've mentioned only one rather involved extensibility feature. There are other very powerful, yet approachable, options for the Actions panel. Specifically, check out all the Preferences and Auto Format Options found under the Actions panel's options menu (see Figure 2.6).

Figure 2.6. There are many other nice options available from the Actions panel's options menu. (Click where the pointer is shown.)

A True Debugger

Although Flash 5's Debugger was quite useful, it wasn't really a "debugger." I'd call it a "watcher" or an "inspector." Flash MX has a true debugger. If you're having trouble with your code (and, I'm sorry, you will everyone does), you can set breakpoints (that cause the file you're testing to pause) and then step through the code one line at a time to investigate (and solve) the problem. The Flash MX Debugger not only has more features than the Flash 5 Debugger, it was redesigned and makes more sense. In addition, the remote debugging option is well thought out and very usable. You'll learn much more about the Debugger in Chapter 6, "Debugging."

New Objects

In programming, objects are sets of related features that all follow consistent rules. Sometimes objects relate to something onscreen (such as the Movie Clip object), and sometimes they're more ephemeral (such as the Sound object). Anyway, there are a bunch of new ones in Flash MX. Let me run down a few of the more significant objects and tell you how they will affect your life.

Not only do instances of buttons and text onscreen now have instance names (such as "Movie Clips"), they have most of the same properties. For example, you can set a button's position onscreen using script (whereas in the past only Movie Clip instances could be affected in this way). And just like there's a Movie Clip object, there are Button and TextField objects as well. (Note that Static text is excluded only Dynamic Text and Input Text are instances of the TextField object.)

Whereas clips, buttons, and text are pretty concrete, the new TextFormat object is not. Basically, the TextFormat object is a pretty powerful way to store detailed formatting information. You'll need to apply it to onscreen text, however, to see anything. You'll see how it works with the TextField object in Chapter 10, "Keyboard Access and Modifying Onscreen Text."

Another new object, called LoadVars, effectively replaces both the Movie Clip method loadVariables() and the confusingly similar loadVariables() function. The benefit to using the LoadVars object is that you can now determine how much data has loaded and even automatically trigger a function when all data has loaded. You'll learn about LoadVars in Chapter 16.

The Stage object gives you a way to both gain information about a movie's settings (its dimensions, for example) as well as to monitor whether the Stage size is changing. Once you learn about "listeners" (in Chapter 10), you'll be able to figure out the Stage object. You'll also see some applications of this feature in Workshop Chapter 13, "Drawing Graphs."

Finally, although I don't want to go into detail here, let me mention that the whole object-oriented design of ActionScript has been revisited and improved. One big enhancement is that you can create your own classes based on the built-in Movie Clip object. Specifically, you can make your own Movie Clip that inherits all the basic features of regular clips and then adds more homemade properties and methods. It's not as though you have to use this feature in every project (it can actually mean a lot of upfront planning), but in addition to making programming geeks happy, it means complex components can be mixed and matched and everything works without conflicts.

Understanding objects isn't terribly difficult; knowing how to apply them to your projects is a bit more work. You'll learn all about objects through this book I promise. Just realize that they don't have to be difficult to use (I promise that, too).

Runtime Drawing

Flash MX adds the ability to draw lines, curves, and solid, radial, or linear fills. When you see how, it might appear like a ton of programming that's good only for drawing primitive shapes or really cheesy gradients. In nearly every case, it will seem easier to just draw the graphic by hand. However, the power of runtime drawing is that it happens at runtime, so it can be based on timely information or specific preferences of the user. In Workshop Chapter 13, for example, you'll see how to draw customized graphs for the user. Basically, instead of manually drawing every permutation of possible results (ahead of time), you can create drawings dynamically.

Major Changes to ActionScript Events

Obviously, we've already seen many major changes. The following section will quickly look at major changes to the way scripts can respond to various events. The idea of an event driven-language such as ActionScript is that scripts are written to respond to specific events (the user clicking a button, for example). Flash MX offers additional ways for your scripts to tap in to those events.

Callback Functions

Callback functions are a new way for you to define which scripts should execute when a particular event occurs. You can still use the old (and perhaps more intuitive) way of placing code right on a button. For example, you can type the following code into the Actions panel while a button instance is selected:

on(press){   play();  }

This translates to, "On the event that the button is pressed, do the script play()." Actually, you could even write the preceding script in one line, as follows:

on(press){play();}

It's the same thing. It turns out that a named instance of a button also has an onPress event to which you can assign a function. For example, if your button instance is named my_btn (the default Auto Completion suffix for buttons is _btn), you can use the following code in a keyframe (in the timeline where the button is present):

my_btn.onPress=function(){play();}

It looks sort of the same as our one-liner in the preceding example, and the effect is the same. We'll cover all the syntax details later, but for now, just consider why this might be useful. The first benefit I see is that all the code can be consolidated in one place a keyframe instead of being scattered all over on separate button instances. Another benefit is that you can change the onPress event to trigger a different function later. For example, if you later execute the script my_button.onPress=function(){stop();}, the same button will now make the movie stop (rather than play). Again, we'll go over all the details, but I've found this new way of writing scripts in a keyframe instead of on separate instances to be very addictive.

Listeners

Listeners are confusingly similar to callback functions because they also enable you to define which scripts are to occur when certain events happen. However, listeners are easier to mix and match because you can have several different scripts all listening for the same event. In the preceding example using the onPress event, we could have only one callback function defined at a time. Assigning a new callback function would erase the old one. With listeners, it's cumulative; you can add or remove listeners at will.

Now, one tricky limit is that not all events can be "listened" for. That is, my comparison to onPress isn't totally fair because an onPress listener is not available. (It's still a good example, though.) You'll find that there are only a few listeners available for any particular object. Perhaps the easiest one to understand is the onChanged listener for the TextField object. It enables you to trigger a script any time the contents of a specified text field change. Say you have an input field into which you want users to type a number. You can add a listener that executes a script every time they type into the field. Perhaps you want to determine whether the value is too high or too low. You can later remove this listener or add another perhaps one that checks whether users actually typed a number. Although there are other ways to restrict what users type, listeners are a convenient way to automatically trigger scripts at the right time. You'll learn more about listeners in Chapter 10.

Watchers

Callback functions and listeners give you a way to trigger scripts any time an event occurs. In comparison, watchers let you trigger scripts any time a specified variable changes. Variables are just a way for you to store information for later retrieval. For example, you might have a username variable that contains the current user's name (the name typed in, that is). Maybe you have a million different places in your movie where the username variable can be changed. It's very simple to add a script that effectively says, "Any time the username variable changes, I want you to do these things." Naturally, you'll need to learn the details of exactly how this works and you will in Chapter 14, "Extending ActionScript."

Timing Controls

Even though ActionScript is an event-driven language, you can still write scripts that appear to trigger automatically instead of waiting for a particular event. Really, the best way to think of this is that the passing of time is really an event. Each time the second hand on the clock ticks is an event. With Flash, you can actually write scripts that get triggered more frequently than that.

SetInterval

In Flash 5, you could trigger a script every enterFrame, meaning that if the frame rate was 12 frames-per-second, the script would execute every 1/12 of a second. It was kind of a pain because you always needed a Movie Clip instance on which to attach such a script. In addition, you were always limited by the movie's frame rate, which should always be kept at a reasonable level. Anyway, the new setInterval() and clearInterval() functions enable you to indicate a script that you want to trigger automatically as frequently as you specify. We'll get into the syntax later, but you can just type the following script into a keyframe, and provided that you have a clip on the Stage with the instance name "clip," you'll see it move to the right every second:

setInterval(function(){clip._x+=20},1000);

The first parameter is the script that you want to execute (here, a script that increases the clip's _x property by 10), and the second parameter is the interval (in milliseconds) between each execution. If you change the 1000 to 100, it will move every 100 milliseconds. (That's 1/10 of a second.) You'll learn more about the setInterval() function in Chapter 14.

Note

It might seem as though most of the cool stuff doesn't come up until later chapters. That's only partially true. First of all, there's plenty of new stuff in every chapter. Ultimately, though, to really exploit the timing features, watchers, listeners, and callback functions (not to mention objects), you really need a solid foundation of the basics. This is not one of those deals where you must first pay the price of long, hard work. It's more like this: Once you get the basic idea, you'll be able to apply the same techniques to many concepts. That is, it's super consistent, so you'll reach a point where things start to really make sense.

Sound Duration and Position, and the onComplete Event

Three new features of the Sound object make it much more usable than before. Specifically, you can access any sound's total duration and current position, which simplifies tasks such as displaying the visual progress of a sound. Of course, if you continually check to see if the current position is equal to the total duration, you'll know the sound has finished. However, there's an even better way: the onComplete event. That is, you can define a script to execute the instant a particular sound finishes playing. These are great additions.

Oh, and if you haven't heard, Flash MX lets you load external .MP3 audio files! This means that your movies can remain small and load sounds only when the user requests.

Web-Specific Features

I suppose nearly everything is web-specific in Flash. It's just that a few new ActionScript features are particularly web-centric.

allowDomain Method

There are a few objects that I didn't mention earlier specifically, the System object. The current documentation doesn't reveal a whole lot here, but within the System object is a method called allowDomain(). This particular method overcomes an old security limitation in Flash that made it impossible to load movies that reside on other web domains. In Chapter 7, you'll see how it works.

Local SharedObject

Simply put, local SharedObjects are like cookies but much more. Now it's simple to store data on the users' computers so that the next time they visit your site you can "remember" anything you bothered to save. For example, you can save their preferences. Perhaps you let them select a background color for your Flash movie and you want it to restore when they come back. Or, you can track the "history" of which parts of your site they've visited. That way, you can show them an introductory animation just once. Subsequent visits will bypass the animation. The coolest part is that the data stored remains in its original data type. You don't have to convert string data (the way you do with nearly every other option). You'll learn about SharedObjects first in Chapter 16, "Interfacing with External Data," and then revisit them in Workshop Chapter 17, "Using the LocalConnection Object for Inter-Movie Communication."

Local Connection

The LocalConnection object gives you an easy way to let one movie trigger scripts in another movie. For example, your web site can include two Flash movies in different cells of a table, and those two movies can communicate. Even if one Flash movie pops up in a separate window, it can send data to another window. This feature will blow your mind! Whenever I demonstrate just a simple example of using the mouse to drag a box in one movie and having another movie's box move at the same time, the audience goes wild. You'll learn all about the LocalConnection object in Chapter 16.

Book Conventions and Expectations

It might seem weird to put this information at the end of Chapter 2, but this is more than just a legend explaining the icons used in this book. Think of this section as "what's new in this edition." Chapter 3, "The Programmer's Approach" the first "real" chapter is where we really start rolling.

New for MX

A "New to MX" icon will appear any time a new Flash MX feature is discussed (see Figure 2.7). This icon will be most interesting to those of you who've used Flash 5. You should see a lot of those icons when you flip through the book! The thing is, I didn't include the icon for everything. This entire chapter would be pretty messy if we had a million such icons so we left them out. Anyway, you'll see the icon for the major changes.

Figure 2.7. Look for the "New to MX" icon to see features new to Flash MX.

Handy-Dandy Formulas

I wrote this book as much for me as for everyone else. That is, I present the information in a way that I would like to see it. After the first edition of this book, I found myself bookmarking certain pages that contained formulas that I use frequently. For example, I can tell you the page where the formula to calculate the distance between two points appears in my old book.

Instead of making a separate index of such handy formulas, I call them out in the text. In most instances the formula is first derived, but if you want to come back to it later, it's nice to see it highlighted in some way. In addition, when you encounter a formula in the text, you should realize that it might be useful later.

Separating ActionScript from "PhillipScript" (and What's a "Foobar?")

One of the hardest things about learning a programming language when you look at examples is separating the elements that are part of the language from the homemade parts the programmer added. If you were learning English, for example, you might have a hard time with the sentence: "Phillip Kerman has a dog named Max." The names "Phillip,""Kerman," and "Max" are not really part of English the same way the other words are. The same issues can come up in ActionScript. Nearly every line of code will have a mix of built-in elements and homemade pieces that the programmer added.

When you see script inside Flash, the Syntax Coloring feature helps by changing ActionScript elements to specific colors but it can still be difficult (especially in a book). As much as possible, I prefix homemade names with "my" (for example, "mySound" or "myText"). The idea is that you will understand this is not some feature of Flash, but something I came up with when making the example. I'm sure you'll start to recognize what's homemade and what's part of the language, but I know (from experience) that it can be difficult at first.

Note

Programmers often use the term "foobar" (or just "foo" and "bar") whenever they are trying show an example with absolutely no context. For example, if you were learning the form of a function, I might show you: function goPlay(frame){}. But there's no indication of what's part of the language and what's part of my example. To separate the form from the content, I could instead use function foo(bar){}, in which case you would know that only the word function is part of the language. I don't think you'll see "foobar" in this book, but it comes up in many programmers' examples. You may be interested in researching the history of "foobar" and its Army-speak ancestor, the crude acronym FUBAR. Although "foobar" is cleaned up for programming, it's utterly meaningless.

Prerequisites

Now I tell you about the prerequisites? Well, really, there aren't many. It's quite possible to go through this book and learn ActionScript without a base knowledge in Flash. It sure helps if you can build the basic framework of a Flash movie. Even more important is that you see the application for scripting. That is, if you know what's involved doing things by hand in Flash, you'll better appreciate how scripting makes things easier.

I see the ideal reader as someone who is familiar with drawing, animating, and structuring a Flash movie. You should be able to make nested Movie Clips and keep track of where you are (whether you're nested in a clip or in the main timeline, for example). You don't need to be a math wiz, but if you are, you might get bored with a few of my explanations. My goal is to turn Flash users into Flash programmers. I'm sure if you have the same intention, you'll do fine.

Summary

All this new stuff might appear to be overwhelming. Just remember that you can learn only one thing at a time. ActionScript really has never been more empowering. It's still work, but hopefully the way this book is presented will help things make sense and provide plenty of practical applications.

If you already have experience programming in Flash, you really should try to open up to some of the new techniques that are now possible. In a way, learning new things means breaking old habits, but I can assure you that every minute invested will pay back in hours of time saved.

In any event, you should see all these killer features not as "a ton of stuff to learn," but rather as a huge opportunity to reach a higher potential. I'm excited, partially because I'm nearly done writing the book, but mainly because I can see myself getting more efficient every time I script a project. It's true that you never stop learning!

CONTENTS