Macromedia Flash Professional 8 UNLEASHED [Electronic resources] نسخه متنی

Tools of the Trade

When it comes time to debug, Flash has several options that will help you. Some of the simplest options use the Output panel as a means of getting information to you. You can open the Output panel at any time by going to Window, Output (F2), as shown in Figure 17.3. When you test your code or movie, the Output panel is used to display errors in your code, but you will also learn how to manually send information to it.

The first option for sending information to the Output panel that you can use in your own code is the trace function.

The trace Function

The trace function is one of the most widely used tools for debugging in Flash because of its ease of use and capability to be added or removed from your code. The trace function will take any information passed to it and display that information at runtime in the Output panel. You can place TRace functions in any part of the code in either frame actions or object actions. Here are a few examples of trace functions:

trace("david");         //trace a simple string
trace(129);             //trace simple numbers
trace(1 + 41);          //trace answers to expressions
trace(15 < 35);         //trace results from comparisons
trace(getTimer());      //trace the results of functions
trace(rec_mc._x);       //trace information about objects on the stage
trace(test_array);      //trace entire arrays of information

If you were to test the preceding code, the Output panel would appear similar to Figure 17.3, with some exceptions, because a couple of the trace functions refer to objects that may not be present in your file, such as the array and movie clip.

NOTE

It is important to note that the information being sent to the Output panel will display only from within Flash and Flash's test environment. It will not appear when using your finished file (.swf).

When you are done debugging, you can remove all the trace statements manually, or turn them all off at once in the Flash tab of the Publish Settings (File, Publish Settings) and select Omit Trace Actions. This will prevent the trace functions from working when you test the movie, but they will still be present in your source file if you need to use them again.

List Options

You can also send other information to the Output panel when debugging. You can list all variables or all objects in your movie during testing. To list this information, test your movie by going to Control, Test Movie (PCCtrl+Enter, MACOpen Apple+Enter). Inside the test movie screen, select either Debug, List Objects (Ctrl+L) or Debug, List Variables (Ctrl+Alt+V). You will see something similar to the following two figures. And when you list the variables, notice a special one that you did not create$version. This variable is available to you during runtime, and it lists the type of operating system and the version number for the current player running. This can also be helpful if you have content for specific versions of Flash, so make special note of it.

These options in the test environment can become valuable when you're trying to figure what the value of several variables are during runtime, as well as which objects are available and what some of their properties are.

NOTE

It is important to understand that when you use these listing options, only the objects and variables currently present at the point of the movie you are in will be listed. For instance, if you delete a variable with ActionScript before the point in your movie where you are, that variable will not be listed.

The Error Object

The Error object, introduced back in Flash MX 2004, will probably be familiar to you if you have worked in other programming languages. It is used to hold error messages that can be thrown directly to the Output panel, or they can be caught by either a catch or finally action while inside of a try statement. They are most commonly used with testing functions.

In this example of code, we will create a try statement, and then use conditionals to trigger the error.

//create a password
var myPass:String = "testing";
//test the password using a try statement and a conditional
try{
if(myPass != "password"){
throw new Error("Incorrect password");
}
}
//last resort
finally{
//everything is fine
}
//simple trace action to see if the reader gets this far
trace("test");

When you test this code, the error will be thrown to the Output panel. But make special note that the trace function at the end of our code was not sent to the Output panel. This is because when a throw takes place, it stops the ActionScript reader from moving forward. If you change the myPass variable to "password," the error will not be thrown, and the trace function will be run.

In the next example of using the Error object, we will use it inside of a function we build. This time, instead of sending it directly to the Output panel, we will catch it using the try and catch statements, and then send it to the Output panel. You can, of course, catch these errors and do other things with them, but for this example, we will still send it to the Output panel to see immediate results.

//create the function
function greaterThan(num1:Number, num2:Number):Void{
//compare the numbers
if(num1 < num2) {
throw new Error("The first number is not greater than the second");
}
}
//try the function
try {
greaterThan(12,15);
} catch (theError) {
//trace the error if there is one
trace(theError.toString());
}

Notice that this time we are using the throw statement inside a function. This means that for the error to be shown, it must first be captured with the catch statement.

Those are just two ways the Error object can be used to improve debugging. The Error object is great if you have multiple bugs and want to debug them one at a time, because the Error object can stop the rest of the ActionScript from being run.

Sizing Up Your Project

As mentioned before, not all debugging involves finding and fixing errors. Sometimes you will have to debug the performance and file size of your project. For example, because SWFs are a streaming file type, they will begin playing instantly in your browser. The problem is that sometimes the movie will reach a frame that has not completely loaded yet, and there will be a pause on that frame while the loading catches up. Using a preloader to preload all the content before it moves forward is an easy solution for this, but not always a warranted solution (see Chapter 13, "The Movie Clip Object," for more information on preloaders). Sometimes, you just need to adjust the frame that's slowing up the file, and it will stream fine. And Flash has two tools to help you track down heavy frames.

The Bandwidth Profiler

When testing your movie in Flash's test environment, note that there is a feature that is not turned on by default, called the

Bandwidth Profiler . This tool displays your file frame by frame in a vertical bar-graph representation, as shown in Figure 17.6, so that you can quickly spot the trouble areas of your file. To open the Bandwidth Profiler, test your movie (Control, Text Movie), and then select View, Bandwidth Profiler (Ctrl+B).

You have two options for viewing this graph: Streaming Graph or Frame by Frame graph. By default, Streaming Graph is selected.

As you can see from Figure 17.6, frame 12 is above the red line, so some work needs to be done in that frame to make it stream correctly. You can also test for streaming in the test environment by selecting View, Simulate Download (Ctrl+Enter) from inside the test environment. There are also bandwidth options under View, Download Settings that simulate different connection speeds.

Generate Size Report

Another tool in Flash for monitoring the size of your file is the Size Report. The size report can be generated automatically by going to the Flash tab of the Publish Settings (File, Publish Settings) and checking the Generate Size Report option. Then when you test your file, information will be sent to the Output panel and a text file will be created right beside the FLA you are working in with the same name plus the word "Report" in it.

Table 17.1 shows an example of what the size report might look like:

As you can see from the preceding output, the size report gives much more information about your file than the bandwidth profiler does. Not only does it show the byte size in each frame, it also keeps track of the total running byte size as you move through the frames. You also get information about each symbol in the library and bitmaps. You can even see the file size of just the ActionScript in each frame and symbol.

All of these tools that we have gone over in Flash are great for debugging your project, but sometimes you will need something more directly geared toward finding bugs in your code.

The Debugger

The debugger is a special panel included in Flash that makes it easy to track values and hierarchies in your projects.

In the first example of using the debugger, we will walk through a simple login page that will look for the user's login name and password. You will need debugger1.fla from the website to go through this example.

if(login == "admin" &&  pass == "letMeIn"){

if(login == "admin" &&  password == "letMeIn"){

This example was a simple fix, and the debugger will work just as well with huge applications as it did with this little login screen.

The debugger can also be used to adjust visual properties and values of content on the stage at runtime. This next example will have an image that is labeled, but something does not look right with the label. We will adjust its properties in the debugger so we can see what they look like at runtime. You will need debugger2.fla from the website.

Now that you are satisfied with how the label looks, you can go back to the ActionScript and make the changes, because even though you changed them in the debugger, they do not stay there when you close the test environment. This is so you can make changes to properties of several objects on the stage without fear of messing up your original code. This technique of changing things at runtime will also work on objects created manually.

In this section, you have learned how to debug your projects at your own workstation, but what if you want to debug your project at home and don't have the file, or you want someone else to debug your project and they are not onsite?

Remote Debugging

Debugging from remote locations is a tremendous time-saver when you're working in a team environment where not every team member is at the same site. Remote debugging will allow you to set up your file, with a password, so that users who have Flash in other geographical locations can assist in the debugging process.

The first thing you will have to do is set up your file to allow remote debugging. You can use any of the files mentioned in this chapter, or create your own from scratch.

That was the first part; the next part is to actually connect to it using remote debugging.

After the password is entered, you should be able to debug as if the file were running on your machine.