home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam    

Book HomeActionScript: The Definitive GuideSearch this book

Chapter 19. Debugging

So far we've explored a lot of techniques and also the syntax to accomplish many goals. Inevitably, however, when you begin writing your own ActionScript, you'll encounter innumerable errors (especially at first when you are still making syntax and conceptual errors). Do not lose heart! Even experienced programmers spend a lot of time debugging (fixing broken code).

It is important that you test your product thoroughly so that you can find the bugs in the first place. This means testing in various browser brands and versions of those brands on all platforms that you intend to support. Test under different flavors of Windows and, if applicable, older versions of the Flash plug-in, which you can find at:


A discussion of testing and quality assurance (QA) is beyond the scope of this book. Suffice to say that you should have a testing and QA process in place and a bug report form on which you can receive reports with sufficient detail (such as the platform, browser version, Flash plug-in version, and reproducible steps) for you to reproduce the error, which is the first step toward fixing it.

Debugging is an essential part of programming and what sets great programmers apart from average ones. Beginners are often happy if a bug that was seen earlier inexplicably disappears. Experienced programmers know that the bug will undoubtedly resurface at the most inopportune time, and although it is intermittent (perhaps especially so), it warrants further investigation. On the other hand, inexperienced programmers tend to shy away from error messages or be unnerved by obvious errors, whereas skilled programmers rely heavily on error messages and know that easily reproducible errors are the easiest kind to fix.

Successful debugging requires logical, disciplined investigative skills and a decent understanding of troubleshooting tools. In this chapter, we'll briefly consider the basics of debugging tools and some general techniques for solving code problems. Remember that debugging is characterized by the systematic challenging of our assumptions. Any given problem is often caused by some other problem upstream (i.e., the disease). We'll use the debugging tools to investigate whether things are in fact operating as designed, and that will lead to an understanding and resolution of the manifest bug (i.e., the symptom).

19.1. Debugging Tools

ActionScript comes equipped with the following debugging tools:

  • The trace( ) function

  • The List Variables command

  • The List Objects command

  • The Bandwidth Profiler

  • The Debugger

All of these tools are used in Test Movie mode. To enter Test Movie mode, we export a movie from the authoring tool using Control Test Movie.

In addition to these formal debugging tools, Flash also sends error messages to the Output window when a movie is exported or Check Syntax is performed. (Check Syntax is a command listed under the arrow button in the top right of the Actions panel.) Error messages often identify the exact cause of a problem down to the problematic line number in a block of source code. Comprehensive explanations for the various error messages are provided in Macromedia's ActionScript Reference Guide.

Note that not all bugs cause error messages. For example, a calculation that yields the wrong result is a bug even if it doesn't crash your browser. Also note that there are two types of error messages, so-called compile-time error messages that occur when you try to export your scripts and so-called runtime error messages that don't occur until you run your Flash movie and reach the point that causes the error. Compile-time errors indicate some sort of syntax problem such as a missing parenthesis or unclosed quotation. Refer to Part III, "Language Reference", for the exact syntax needed for each command, and refer to Chapter 14, "Lexical Structure", for an explanation of proper ActionScript syntax.

Runtime errors can take a wide variety of forms and may not indicate a problem with the current code under examination but rather may be caused by using the incorrect result of an earlier operation. For example, suppose you try to use the values received back from a loadVariables( ) command sent to a web server. If the Perl script responding to the command didn't supply the correct data in the correct format, you need to correct the Perl script. Your Flash script may be perfectly correct and yet fail because it received incorrect input.

Which brings up an important technique -- defensive programming. You can avoid a lot of errors and potential errors by always checking for potential problematic conditions, which is known as error checking (or sometimes data validation if it pertains to user input). For example, before trying to display the questions of a quiz, you might check that those questions loaded properly. You might also check each question to be sure it's in the correct format for display. If the provided data was improperly entered, you should display an appropriate error message that allows the programmer or the user to take corrective action.

19.1.4. The Bandwidth Profiler

The Bandwidth Profiler is used to simulate movie download at various modem speeds. Using the Bandwidth Profiler, we may gauge the performance of a movie, test preloading code, and track the position of the main movie's playhead during movie playback. Here's how to turn the Bandwidth Profiler on:

  1. While in Test Movie mode, select View Bandwidth Profiler.

  2. Under the Debug menu, select the desired download rate.

  3. To simulate the download of a movie at that rate, select View Show Streaming.

There are many things that can affect Flash performance, such as the assets in use and the rendering demands on the Player. For example, using large bitmaps, rendering complex shapes with many curves, and excessive use of alpha channels can all degrade performance. Asset downloading and rendering times usually dwarf the bandwidth and processor time required for ActionScript to execute. That said, ActionScript is generally much slower than compiled languages such as C.

From an ActionScript perspective, the most time-consuming operations are those that either must wait for data to be uploaded or downloaded or those that are performed repetitively (such as examining a large array).


Displaying items in the Output window is very slow compared to "invisible" operations in ActionScript. If a simple movie seems excessively choppy, try disabling all trace( ) statements, or play the movie outside Test Movie mode.

A discussion of writing optimized code is beyond the scope of this book, but some quick tips should suffice:

19.1.5. The Debugger

The Debugger is a highly useful tool that gives us organized access to the values of properties, objects, and variables in a movie and even allows us to change variable values at runtime.

To enable the Debugger, select Control Debug Movie in the Flash authoring tool (not in Test Movie mode). You may also use the Debugger in a web browser, provided that:

  • The movie being viewed was originally exported with debugging permitted.

  • The Player being used to view the movie is a debugging Player.

  • The Flash authoring tool is running when you attempt to debug.

To export a movie with in-browser debugging permitted, select File Publish Settings Flash Debugging Permitted, then optionally provide a password to prevent prying eyes from snooping around your code. To install a debugging Player in your browser, use the installers provided in the /Players/Debug / folder where you installed Flash on your hard drive. To enable debugging while viewing a movie, right-click in Windows (Ctrl-click on Macintosh) on the movie and select Debugger.


Not all versions of the Flash Player have a corresponding debugging Player. Check Macromedia's support site for the newest versions of the debugging Player,http://www.macromedia.com/support/flash.

The top half of the Debugger (the Display List) shows the movie clip hierarchy of the movie. To inspect the properties and variables of a specific movie clip, select it in the Display List. The bottom half of the Debugger contains three tabs, Properties, Variables, and Watch, which update dynamically to show the properties and variables for the selected clip. To set the value of any property or variable, double-click its value and enter the new data. To single out one or more items for convenient scrutiny, select them in the Properties or Variables tab, then choose Add Watch from the arrow button in the upper-right corner of the Debugger. All "watched" variables are added to the Watch tab (this lets us view variables in different movie clips simultaneously).

For more information about the mechanics of using the Flash Debugger, consult Macromedia's thorough documentation under "Troubleshooting ActionScript" in the ActionScript Reference Guide. If you've lost your Reference Guide, remember that it's available on Macromedia's web site at http://www.macromedia.com/support/flash and also under the Help menu in the Flash authoring tool.

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.