O'Reilly logo

Learning ActionScript 3.0, 2nd Edition by Rich Shupe, Zevan Rosser

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 1. What Is ActionScript?


What’s New in ActionScript 3.0?

The Flash Platform

Procedural Versus Object-Oriented Programming

The Document Class

Legacy Code Compatibility

Hello World

What’s Next?

While you likely know that ActionScript is the main scripting language of the Flash Platform, and you’re no doubt eager to begin working with the new version, a brief overview of its development will give you some insight into its use—particularly as related to Flash Player and how it handles different versions of ActionScript. This brief introductory chapter will give you a quick look at where ActionScript 3.0 fits into your workflow.

Before we get started, it might help to understand how you get from ActionScript code to a finished file that you can put into a website. If this isn’t news to you, bear with us for just a paragraph or two.

When you publish a Flash file—using Flash Professional’s File✓Publish or Control✓Test Movie—all of the internal graphics and other assets used in your movie, as well as all of the ActionScript code, are compiled into a final file format called a SWF (pronounced “swiff” or “S-W-F”). That is, a part of your Flash Platform application of choice (such as Flash Professional) contains software called the compiler. This software converts all of your human-readable scripts into an optimized, machine-readable format. It combines that code with your assets into a single SWF file that Flash Player can decode and play back for all to see.

Although your SWF can load external assets not already compiled into your SWF (such as an MP3 or a video), any asset that you imported or embedded and all scripts—even if they originate outside the FLA (pronounced “flah” or “F-L-A”) file—must go through this compilation process to be included in the SWF. This is why you must publish a new SWF every time you make a change to your code. It’s also why you don’t have to distribute ActionScript files with your SWF, even if you created external files, such as classes, when coding. Distributing ActionScript files with your SWF won’t affect playback, but it may expose your source code to the public. This is fine when you’re contributing code for others to learn from, but it won’t make a client happy if you’re doing work for hire!

For most users, the compilation process occurs behind the scenes and is handled by Flash Professional. At the time of this writing, the current version is Flash Professional CS5, but most of this book is compatible with versions dating back to Flash Professional CS3.

Other applications, such as Adobe’s Flash Builder (or its predecessor Flex Builder), Power Flasher’s FDT, the open source FlashDevelop, and even text editors in combination with a command-line compiler, can transform ActionScript into SWFs. However, this book focuses primarily on Flash Professional as an ActionScript editor.

Many examples will work seamlessly in any ActionScript editor; other examples will rely on symbols found in the library of a sample Flash file (FLA). This will be discussed briefly in the The Flash Platform section of this chapter, but be sure you’re comfortable with this workflow before investing any time in these examples. If your primary goal is to become a Flex developer, for example, with an equal emphasis on that technology’s MXML syntax, you may want to pick up a companion to this text that focuses more significantly on Flex, such as Learning Flex 4 (O’Reilly).

  • What Is ActionScript 3.0? Every new version of ActionScript introduces new features. ActionScript 3.0, however, was written from scratch (not built on prior versions of the language) and is handled entirely separately from previous versions of ActionScript anywhere the language is used. This intentional branching allows for syntax improvements and significantly improves performance, but also makes it more difficult to use multiple versions of ActionScript at the same time.

  • The Flash Platform. ActionScript 3.0 can be used in Flash, Flex projects, and AIR (Adobe Integrated Runtime) desktop applications, each of which are part of what is collectively known as the Flash Platform. Although they affect only a small portion of the language, differences in these environments prevent ActionScript 3.0 from working exactly the same way in every application that is part of the Flash Platform. The fundamentals, however—indeed, the bulk—of the language, are the same throughout.

  • Procedural Versus Object-Oriented Programming. A lot of attention has been focused on the object-oriented programming (OOP) capabilities of ActionScript 3.0, and the language’s power really shines in this area. However, embracing ActionScript 3.0 doesn’t mean that you must become an expert in OOP. Using Flash, it is still possible to write scripts in the timeline, using functions to organize more complex code. This is commonly called procedural programming. If you prefer object-oriented programming, enhancements to ActionScript’s OOP structure make version 3.0 more robust and bring it more in line with the features of other OOP-based languages (such as Java). This also makes moving between such languages a bit easier.

  • The Document Class. Object-oriented programming is not for everyone, but for those starting on the OOP journey, Flash offers a simple stepping off point in the Document class. Using this feature, you need only specify an external ActionScript class file as your starting point, and no timeline script is required.

  • Legacy Code Compatibility. Because ActionScript 3.0 can’t mingle with previous versions of the language in the same file, developing projects that support older code is a challenge. We’ll briefly introduce the issues involved and point to a technique that makes possible some communication between ActionScript versions.

  • Hello World. This chapter will conclude with you writing your first ActionScript 3.0 application. We’ll dive into some syntax for text manipulation, but don’t worry: we’ll cover the material in more detail in a later chapter. This exercise is just to get you started and build a little confidence.

What’s New in ActionScript 3.0?

If you’re familiar with ActionScript or you’re learning it based on experience with another programming language, you may want to know what ActionScript 3.0 has to offer. Although the third major version of the Flash Platform’s primary scripting language contains much that will be familiar to users of prior versions, it’s probably best to think of ActionScript 3.0 as entirely new, for a few simple reasons.

First, a few things are quite different, such as how events are handled and the way assets are displayed. Second, subtle changes run throughout the language. (These are usually small concerns, such as a slight change in the name of a property, but if you are used to ActionScript 2.0, for example, old habits can die hard.) Most importantly, ActionScript 3.0 has been rewritten from the ground up and uses a different code base than prior versions of the language. This optimization provides relatively dramatic performance increases, but it means that ActionScript 3.0 code cannot be mixed with prior versions of the language in the same file.

Regardless of your experience level, don’t let the newness of ActionScript 3.0 intimidate you. It’s true that its learning curve is steeper than that of prior versions, but that is usually a function of its robustness more than one of difficulty. Typically, whether you are coming to ActionScript 3.0 from a prior version of ActionScript or another language altogether, there is an adjustment period during which users must occasionally adapt to a new way of doing things.

Here’s a look at some of the highlights of ActionScript 3.0. Keeping these benefits in mind may help make it easier to learn a robust language, or accept change—particularly when that change may initially seem tedious or overly complicated. Select new features include:

Detailed error reporting

ActionScript 3.0 supports strict data typing of variables, arguments, values returned from functions, and so on. Chapter 2 discusses data typing in depth, but it boils down to telling the compiler and Flash Player which kind of data you want to work with at different points within your project code. This allows the compiler to warn you if you use the wrong data type, catching related errors. ActionScript 3.0 supports static data type checking, which occurs at compile time (when publishing your SWF), and improves dynamic data type checking, which checks for errors at runtime. In ActionScript 3.0, errors will no longer fail silently. Understanding this fully in this overview isn’t important, and the benefits of data typing will become apparent after reading Chapter 2—and even more so after gaining a little experience with ActionScript 3.0. For now, just take heart knowing that error checking and reporting are more vigilant than in any prior version of ActionScript.

Syntax improvements

Syntax issues have been unified and cleaned up throughout the language. For instance, some property names have been clarified and made consistent by removing leading underscores. (Setting the x coordinate of a movie clip, for example, now uses x instead of _x.). Also, former multiple and varying ways of approaching the same or similar tasks have been simplified and made consistent.

New display architecture

The many previous approaches to displaying assets are now consolidated. ActionScript 3.0 has simplified how visible assets, such as movie clips and text fields, are handled, using a new display architecture called the display list. Chapter 4 examines this major change introduced by ActionScript 3.0.

New event architecture

Still another example of improved consistency, all events—such as a mouse click or key press—are handled by event listeners in ActionScript 3.0—essentially listening for a specific event to occur, and then reacting accordingly. The new event model is very powerful when combined with the display list, allowing mouse and keyboard events to propagate through multiple display objects. The event model is discussed in Chapter 3.

Improved XML handling

Working with complex XML documents is a pleasure with ActionScript 3.0. It allows you to reference XML data the same way you reference properties of other objects, such as movie clips or buttons, using a similar syntax. You’ll learn more about this in Chapter 14, but a simple example is referring to an XML node called phone, nested inside a node called user, as user.phone. This is comfortable territory when you remember that a movie clip called mc2, nested inside a movie clip called mc1, is referenced as mc1.mc2.

Additional text options

New text-processing options now allow for much finer control over text manipulation. For example, you can now find the contents of a particular line in a text field, the number of characters in that line, and the character at a specified point (such as under the mouse). Flash Professional CS5 also introduces a brand new text feature called the Text Layout Framework (TLF). This new engine provides a greater degree of text control, including traditional typographic features, automatic text flow, and even support for right-to-left and vertical text layouts and double-byte languages (such as Chinese, Japanese, and Korean, among others). Text is discussed in Chapter 10.

More sound management options

ActionScript 3.0’s sound capabilities are among the jazziest changes to the language. On a practical level, they improve programmatic control over both individual sounds and all sounds playing. Sounds are now placed into separate channels, making it easier to work with more than one discrete sound. Sounds are also funneled through a sound mixer for collective control. You can get the amplitude and frequency spectrum data from sounds during playback, as well as from microphone input. Chapter 11 covers sound in detail.

New access to raw data

For more advanced needs, you can access raw binary data at runtime. Individual bytes of data can be read during download, during sound playback, or from bitmap data, to name a few examples. These bytes can be stored in a large list and still be accessed quickly and efficiently. We’ll show an example of this technique in Chapter 11 when discussing sound visualization.

New automatic scope management

In a programming language, the word scope is sometimes used to define the realm in which an object, such as a movie clip, lives. A movie clip might exist in one part of a Flash movie but not another. For example, a child movie clip might be nested inside one of two movie clips found in the main timeline. That nested movie clip exists within one clip but not the other. Its scope, therefore, is restricted to the movie clip in which it lives, or its parent. Programming structures have specific scopes, as well, and ActionScript 3.0 greatly simplifies this concept by automatically keeping track of where a particular block of code was defined—so you don’t have to.

Improved object-oriented programming

If you’re familiar with object-oriented programming, you’ll be glad to know that ActionScript 3.0 supports this structure well. If you’re new to OOP, don’t worry: we’ll introduce it in this book at a comfortable pace. We’ll focus on syntax throughout by using simple examples, and we’ll start to discuss OOP in greater detail in Chapter 6. If you’re already familiar with OOP, you may be happy to know that sealed classes and new namespaces, among other things, have been added to ActionScript 3.0. Most classes are sealed by default, meaning the compiler recognizes only those properties and methods defined at compile time. This improves memory usage and performance. However, if you need to add properties to an instance of a class at runtime (for example), you can still use dynamic classes such as the MovieClip and Object, and you can make your own custom classes dynamic. Additionally, namespaces, including the ability to define custom namespaces, allow finer control over classes and XML manipulation.

The Flash Platform

It’s important to note that this book focuses primarily on developing ActionScript 3.0 applications using the Flash Professional application (also commonly referred to as an integrated development environment, or IDE). However, ActionScript 3.0 is the programming language used in Flash Platform technologies, as well—notably AIR and Flex.

AIR is the Adobe Integrated Runtime application, a sophisticated way of delivering your applications to the computer desktop, rather than through a web browser. Flex is another technology for creating SWFs that includes not only the ActionScript 3.0 language, but also MXML, a tag-based language that is part of what is commonly called the Flex Framework. This book will not discuss MXML or the Flex Framework at all, but most of the ActionScript you learn herein can be used in ActionScript-only Flex projects.


AIR projects can also be created from HTML, JavaScript, and PDF, but ActionScript 3.0 is a large part of its appeal and the language most relevant to this discussion.

The existence of AIR and Flex means that the scripting skills you develop using Flash Professional will be largely applicable in other areas of the Flash Platform, extending your reach as a programmer. There are, however, some differences between these technologies that are important to understand when examining the big picture of cross-application scripting.

For instance, each technology adds some features that are not available to the others. Using a feature that is specific to AIR or Flex, for example, means that your code may not compile in Flash Professional. The thing to keep in mind is that the ActionScript 3.0 language skills you develop will ease your move between these applications and even allow you to work with different authoring tools or compilers to create your finished product.


This book is written for readers who have some familiarity with scripting but are new to ActionScript 3.0, and it assumes a working knowledge of the Flash Professional interface. See the Preface for more information about this expectation.

While virtually all of the code in the book applies to any tool that supports ActionScript 3.0, some of the examples use assets that are embedded within FLA files—the main document format used by Flash Professional. The companion website, http://www.LearningActionScript3.com, contains information about using the examples with applications other than Flash Professional. See the “Using the Book Examples” post as a starting point for learning more about this process.

Procedural Versus Object-Oriented Programming

Much discussion has been made over the pros and cons of procedural and object-oriented programming, and many who are new to ActionScript 3.0 have been led to believe that using OOP is the only way to program in ActionScript 3.0. This is not the case. Object-oriented programming is very powerful, and you’ll probably want to use it when you’re more comfortable with the language. However, it’s just one possible way to write ActionScript. We’ll introduce OOP slowly throughout the book, and we’ll try to encourage you to learn OOP by presenting some exercises that use its methodologies. We’d like to reassure you, however, that OOP isn’t required to program the Flash Platform, or to use this book.

To put this into an ActionScript perspective, consider a little background on the language’s evolution. ActionScript started as a sequential programming language, meaning that scripting was limited to a linear sequence of instructions telling Flash what to do in a step-by-step manner. This approach to scripting was not very flexible and did not promote reuse.

As the language evolved, it became a procedural programming language. Like sequential programming, procedural programming relied on a step-by-step set of instructions, but introduced a more structured, modular approach to scripting. Procedures, otherwise known as functions (or sometimes subroutines), could be executed again and again as needed from different parts of a project, without copying and pasting copies of the code into the ongoing sequence of instructions. This modularity promoted reuse, and made the code easier to edit and more efficient.

Scripters in search of an even greater degree of modularity and reuse gravitated toward object-oriented programming. OOP languages create programs that are a collection of objects. Objects are individual instances of classes—collections of code that are self-contained and do not materially alter or disrupt each other. Creating an instance of a class, also referred to as instantiation, is much like creating an instance of a library symbol in Flash Professional. Just like movie clips dragged from the library onto the stage, multiple instances of that movie clip symbol can be altered without affecting one another, and without affecting the original from which they were derived.

Using OOP, however, you can extend this idea much further. One example of extending an object-oriented system is the use of inheritance—the ability to derive classes from other classes, passing on specific characteristics from the base class, or parent class.


The programming terms parent, child, sibling, ancestor, and similar words and phrases mean much the same as they do when used to describe families.

One simple example occurs when referring to symbol instances such as movie clips, which can be nested within each other. The upper- or outermost movie clip is sometimes referred to as the parent (there is even an ActionScript 3.0 property called parent), and the clips nested inside are sometimes called children. Similarly, two movie clips at the same hierarchical level are siblings, and clips that are more than one parent up the chain of nested clips are called ancestors.

In general, if you liken these terms to their everyday uses, referring to families, you will readily grasp their meanings.

Consider, for instance, designing an OOP application that simulates a set of transportation vehicles. You might start with a generic Vehicle class that includes traits common to all vehicles, such as the basic physics of movement. You might then extend Vehicle to create three subclasses: GroundVehicle, WaterVehicle, and AirVehicle. These classes would alter or introduce vehicle traits, making them specific to ground, water, and air travel, respectively. However, these classes might not yet be complete enough to represent an actual vehicle. Further derived classes might be Car and Motorcycle (descending from GroundVehicle), Boat, and Submarine (descending from WaterVehicle), and Plane and Helicopter (descending from AirVehicle). Depending on the complexity of your system, you can carry on this process, creating individual models with individual settings for fuel consumption, friction, and so on.

An example of inheritance
Figure 1-1. An example of inheritance

As you can probably imagine, this approach to development adds additional power, flexibility, and prospects for reuse. These benefits, among others, sometimes position object-oriented programming as the best approach to a problem. However, as we implied at the start of this section, there is a tendency among some programmers to believe that OOP is the best solution to all problems or, effectively, the only solution. This is flat-out untrue.

OOP is often best for large projects or for working with a team of programmers, but it can be overkill for small projects. Additionally, for the uninitiated, it can significantly increase the learning curve and distract from key topical concepts during your studies. In short, OOP is not always the best tool for the job. Procedural programming still has its place, and Flash Professional allows you to explore and employ both programming paradigms.

This book attempts to introduce material using both procedural and OOP approaches where appropriate. Using object-oriented practices is a fine goal, and one that we will encourage. However, we will try first to use simple procedural syntax to focus on the material central to each chapter, highlighting syntax and explaining how and why each topic should be addressed in code.

In general terms, we will focus on procedural programming prior to Chapter 6. Chapter 6 introduces OOP using a simplified version of the vehicle metaphor and serves as a transition chapter between procedural and OOP practices. Beginning with Chapter 7, chapters will introduce new concepts using simple timeline syntax and, when appropriate, include an applied OOP example.

This is our preferred approach to presenting material for all possible users—in both procedural and OOP formats. It is our hope that, regardless of your skill and experience, you will hone in on the topics at hand, and then choose to work using the timeline or classes based on your comfort level.

The Document Class

If you want to start thinking in OOP terms right away, you can easily take a step in that direction. Remember that this is not necessary to get started and that you should feel free to skip this section if you don’t want to be exposed to classes yet. You won’t lose any momentum if you decide to skip ahead, as all of this material will be discussed again in Chapter 6.

Flash Professional introduced a new feature that simplifies associating a main class, or primary entry point for your application, with your FLA. In Flash Professional, this class is called the document class, and it does all the work of instantiating the class for you. This means you don’t need any code in the timeline at all and can edit your code not only in Flash Professional, but also in the external text editor or development environment of your choice.


If you don’t plan to start using OOP until we roll it out in later chapters, feel free to skip this section as the material is discussed again in Chapter 6. We will provide minimal explanation here just to get you going using document classes, and will explain these concepts in greater detail in later chapters throughout the book.

Let’s start with a simulated chapter example that you might use in the timeline. It does nothing more than use the trace() statement to display text in your authoring environment. In Flash Professional, this text will appear in the Output panel, an authoring-only panel that accepts text output from your file for diagnostic purposes.

In Flash Professional, use File✓New and create a new ActionScript 3.0 FLA file. Select frame 1, and add the following to the Window✓Actions panel:



As discussed previously, this book focuses strictly on ActionScript and assumes a familiarity with the Flash Professional application. If you are unfamiliar with the Actions, Timeline, or Output panels, please consult a reference on the Flash Professional application, such as this book’s companion volume, Learning Flash CS4 Professional (O’Reilly). If you are using another script editor, please consult similar references for your editor of choice.

To accomplish this using a document class, you essentially need to create an external file and enclose this instruction in the correct class syntax.

Users of Flash Professional CS3 and CS4 should use File✓New and create a new ActionScript File (rather than a new FLA document). Users of Flash CS5 Professional will see this option as ActionScript 3.0 Class and most of this will be taken care of for you (Figure 1-2).

Creating a new class in Flash CS5 Professional
Figure 1-2. Creating a new class in Flash CS5 Professional

In the new file, type or edit the following:

1    package {
3        import flash.display.MovieClip;
5        public class Main extends MovieClip {
7            public function Main() {
9            }
11        }
12    }

The first line, along with the closing brace in line 12, defines the class’s package. This is a mandatory structure that tells the compiler where your class resides. For simplicity, you will save your file in the same directory as the FLA that will use this class, so no further syntax is required.

Next, you must import any additional classes that your class will reference. The import keyword doesn’t actually import anything; it just provides the location of a class to the compiler so it can validate your code and include the class when creating the SWF. Ordinarily, because this simple example uses only the trace() statement, you wouldn’t need any additional classes to accomplish your goal. However, a document class is essentially a replacement for your main timeline. Behind the scenes, the compiler will use an instance of this class, instead of the main timeline, as the starting point for your SWF. Therefore, your document class should extend, or be derived from, the MovieClip class so that it inherits all the functionality of the main timeline. So, as a result of extending the MovieClip class in line 5, you must import the MovieClip class, as seen in line 3.


When creating a document class, you can also extend the Sprite class, which is essentially a movie clip without a timeline. However, using the MovieClip class for this purpose offers more flexibility.

For example, although it’s not a good idea to combine timeline code with a document class (it’s best to think of the document class as replacing the timeline), it is possible only when the document class extends MovieClip.

For more information, see the “Sprite versus MovieClip” post at the companion website.

Line 5, along with its closing brace on line 11, is the class definition. What you decide to call your class (in this case, “Main”) is up to you, but when naming it you should follow a few basic rules and conventions. The name can’t contain spaces, it can’t already exist in ActionScript, it should start with an alpha character (rather than a number or other character), and it is typically capitalized.

You must add public to line 5 when declaring the class, so that other parts of your program can access it. We’ll cover this in detail in Chapter 6, but you can control which parts of your class are accessible to other areas of your project. For example, if you make something private, it will be accessible only from within the class. Doing so can protect portions of your class from outside manipulation and reduce conflicts with similar functionality that may exist elsewhere in your project. The class, itself, however, must be public so that it can be instantiated.

Line 7, along with its closing brace on line 9, define what is called the class constructor. This is the main function that automatically runs when creating an instance of this class. It, too, must be public and must have the same name as the class. Other functions (if any) can, and must, have unique names, but using the same name as the class identifies this function as the class constructor, so it is executed upon instantiation.

All that remains to complete this document class is to add the lone instruction required to replicate the timeline example discussed previously. The constructor must trace “Flash” to the Output panel, so add the following to line 8:

7    public function Main() {
8        trace("Flash");
9    }

Now that you’re finished writing your class, name your file Main.as and save it to a location you’ll remember. (In a moment, you’ll need to save an FLA to this same location.) When creating a class, you must give the class, constructor, and file the same name—the notable exception being that the file must bear the .as extension.

Now, in Flash Professional, use File✓New and create a new ActionScript 3.0 FLA file. Because this simple example included no custom path instructions in the package declaration in line 1 of your class, save your file in the same directory as your class file. The name of the FLA is unimportant, so you may as well call it main.fla.

Finally, open the Properties panel in the FLA and add the name of your class to the document class field. (It’s labeled “Class” and appears in the Publish section of the panel.) Use the name of the class, not the name of the file. In this case, type Main instead of Main.as, as seen in Figure 1-3.

Adding a document class to your FLA
Figure 1-3. Adding a document class to your FLA

Now compile your FLA file using the Control✓Test Movie menu command in Flash Professional, or Cmd-Return (Mac)/Ctrl-Return (Windows). (For Flash Professional CS5 users, the command is now Control✓Test Movie✓Test.) When your SWF runs, you should see “Flash” appear in the output panel, and your test application will be complete. You can compare your work to the files found in the document_class_example directory in the accompanying source code.

Hereafter, you can try any of our timeline code in a document class of your own. Initially, you probably won’t know which classes to import or how to make any possible changes to variables or similar structures to conform to the class syntax. However, all the sample code will come with an accompanying class file for testing. You can use those files whenever you wish until you get used to the document class format.

Legacy Code Compatibility

If you’ve worked with ActionScript 1.0 or 2.0 in the past—or even if you find yourself updating legacy code created by someone else—it’s very important to understand that you cannot mix ActionScript 1.0 or 2.0 code with ActionScript 3.0 code in the same SWF. You are unlikely to do this if you’re learning from scratch, but you may run into this limitation if you attempt to update legacy projects by adding ActionScript 3.0 code.

If you ever have the need to run a discrete mixture of ActionScript 3.0 and a prior version of the language, such as showing a legacy file within a new demo interface shell, you can do so by loading a SWF. An ActionScript 3.0 file can load a SWF created in ActionScript 1.0 or 2.0, but it cannot directly access the older SWF’s code. A SWF created in ActionScript 1.0 or 2.0, however, cannot load an ActionScript 3.0 SWF.

In Chapter 13, we will discuss how to communicate between these two discrete SWFs using a special process. For now, however, just remind yourself again that you cannot combine ActionScript 3.0 with older versions of the language in the same file.

Hello World

Now it’s time to write your first ActionScript 3.0 application. If you learned about the document class earlier in this chapter, you’ve already done this. That exercise, however, displayed text only within an authoring application like Flash Professional—a technique used for testing and debugging, but not for displaying text in your finished files. In this section, we’ll expand the example to show you how to display text in the SWF files you send out into the world. Using a text field makes a small leap, because we won’t discuss text at length until Chapter 10, but our needs are meager for this example, and you should have no problem at all. Our main goal is to give you a big-picture view of the script-writing process and to give you some experience coding.

Timeline Example

First you’ll create your Hello World application using a simple timeline script to focus on the basic syntax. Then we’ll show you how to use a document class to achieve the same result.

Create a new ActionScript 3.0 FLA file and type the following into a script in frame 1 of the file.


Throughout this book, any time you want to create a timeline script, select a keyframe in which you want the script to reside, open the Window✓Actions panel, and write your code.

1    var txtFld:TextField = new TextField();
2    addChild(txtFld);
4    txtFld.text = "Hello World!";

When you’re finished, test your movie choosing Control✓Test Movie in Flash Professional. You should see the phrase, “Hello World!” in the upper-left corner of your published file.


Because you use variables to store information for later retrieval, naming them in a clear and meaningful way is important. Ideally, the name you choose should convey the purpose of the variable whenever practical. You have a lot of freedom when determining what to call your variables, but there are a few simple guidelines to follow. We’ll discuss variables, including naming requirements and conventions, in Chapter 2.

Line 1 of the script creates a new text field using the TextField class and places a reference to that field into the variable txtFld. Note the colon and reference to the TextField class immediately following the variable name. This is called a data type and makes sure that only a compatible type of data can be put into that variable—in this case, a TextField instance. If you try to put something else into this variable, an error is displayed, which can help you spot problems with your code. Using data typing will save you lots and lots of time, and we’ll talk about it in greater detail in Chapter 2.

Line 2 adds the text field to the display list so it can be seen at runtime. Chapter 4 will explore this further, but put simply, the display list contains everything you can see in your file. For example, a text field is a visual asset, but a sound is not. For the user to see the text field, you must add it to the display list, but this does not apply to the sound. Finally, line 4 puts the phrase “Hello World!” into the text field. Default values for font, size, and color are used to display the text in the field. You’ll learn how to manipulate those characteristics in Chapter 10.


When writing your own class files, you’ll see that other classes referenced therein (such as MovieClip) must be imported so the compiler knows where to find them when publishing your SWF. There are no import statements in this script, however, because Flash Professional does not require that you import any class that is built into Flash player when coding in the timeline.

In short, when referencing a class in the timeline, if that class appears in a flash package—such as the flash.text package in which TextField resides—it doesn’t have to be imported. On the other hand, classes in packages not starting with flash—such as class you write or a class used with a component like fl.controls.Button—must still be imported, even in the timeline.

For brevity, we will follow this guideline, but importing classes does no harm. In fact, as an interface improvement, Flash Professional CS5 will often automatically add import statements to your scripts when you use a class in the timeline—including those from the flash package. If you are using CS5, consider these automatic imports when comparing line numbers between your code and the book.

Document Class Example

To recreate this example using a document class, place the same code inside the constructor of the class—the only function included in this example. Take the following steps to create the files required:

First, create a new ActionScript 3.0 file and type or edit the following code. Save the file as HelloWorld.as and remember where you saved it.

1    package {
3        import flash.display.MovieClip;
4        import flash.text.TextField;
6        public class HelloWorld extends MovieClip {
8            public function HelloWorld() {
9                var txtFld:TextField = new TextField();
10                addChild(txtFld);
12                txtFld.text = "Hello World!";
13            }
15        }
16    }

Next, create a new ActionScript 3.0 FLA and save it in the same directory in which you saved your class. The name of the FLA is not critical. In the Properties panel in that FLA, add HelloWorld to the document class field.

Finally, test your movie. You should see the small phrase, “Hello World!” on the stage in the upper-left corner.

The class syntax here conforms to the syntax described in The Document Class section of this chapter, with two small exceptions. (If you want to complete this portion of the Hello World exercise, and haven’t already read that section, please do so now.) The main difference is that the code in the class constructor differs because its purpose differs. Like the timeline code used to create the first Hello World example, this code uses a text field to display text, instead of the Output panel. The second difference results from this change. Because you are now using the TextField class to create a new text field, you must also import this class in line 4 so the compiler knows to include it.


Congratulations! If you completed one or both of these Hello World examples, you just created an ActionScript-only application. You can compare your work to the hello world_timeline.fla file and/or the files in the hello_world_document_class directory, both found in the accompanying source code at http://www.LearningActionScript3.com.

What’s Next?

Now that you know a little more about ActionScript 3.0 and the Flash Platform, it’s time for a look at some of the fundamentals of the language. By reviewing version-independent concepts at the outset, we can focus on new syntax in subsequent chapters. If you have a lot of experience with ActionScript 1.0 or 2.0, you may wish to skim Chapter 2.

In the next chapter, we’ll discuss:

  • Basic concepts to bring you up to speed quickly, including using the trace() statement as a diagnostic tool to see immediate feedback from your scripts

  • Using variables to store data (including arrays and custom objects that allow you to easily manage more than one value) and data typing to improve error reporting

  • Structures such as conditionals for decision making and loops for simplifying repetitive tasks

  • Functions that can isolate code into convenient blocks that will be executed only when instructed

  • Ways to address Flash objects with ActionScript, including using absolute and relative paths, and the identifier this

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required