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.

Figure 17.3. The Output panel displays information from your movie at runtime.


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.

Figure 17.4. An example of the output for List Objects.


Figure 17.5. An example of the output for List Variables.


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).

Figure 17.6. The Bandwidth Profiler for viewing frame size at runtime.


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:

Table 17.1. Example.swf Movie Report

Frame #

Frame Bytes

 

Total Bytes

 

Scene

1

5,492

 

5,492

 

Scene 1 (AS 2.0 Classes Export Frame)

2

9,897

 

15,389

   

3

10

 

15,399

   

4

10

 

15,409

   

5

358

 

15,767

   

6

3

 

15,770

   

7

1

 

15,771

   

8

1

 

15,772

   

9

1

 

15,773

   

10

1

 

15,774

   

11

1

 

15,775

   

12

1

 

15,776

   

13

1

 

15,777

   

14

1

 

15,778

   


Scene

Shape Bytes

 

Text Bytes

 

ActionScript Bytes

Scene 1

0

 

0

 

6,087


Symbol

Shape Bytes

 

Text Bytes

 

ActionScript Bytes

bigT

292

 

0

 

0

Symbol 1

0

 

0

 

0

PixelFX 4

0

 

0

 

0

thumbMC

0

 

26

 

1,032

PixelFX 3

0

 

0

 

0

PixelFX 1

0

 

0

 

0


Font Name

Bytes

 

Characters

_sans Bold

4742

 

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMN OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{ |} ~


ActionScript

Bytes

 

Location

 

5,465

 

Scene 1:actions:1

 

599

 

Scene 1:actions:2

 

1,032

 

thumbMC:actions:1

 

23

 

Scene 1:actions:5


Bitmap

 

Compressed

 

Compression

 

PixelFX_Element1

 

2,523

 

68,264

JPEG Quality=100

PixelFX_Element3

 

842

 

7,224

JPEG Quality=100


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.

1.

After you have debugger1.fla open, test the movie by going to Control, Test Movie. If you put in "admin" for the login and "letMeIn" for the password, and then click LOGIN, you will notice it does not move to the next frame. Time to debug.

2.

Return to the authoring environment and select Control, Debug Movie. This will test your movie as before, but it will also open the debugger automatically. Notice that the movie is stopped in the first frame; this is to allow you to put breakpoints in your code.

3.

On the right side of the debugger, select Actions for Scene 1: Frame 1 of Layer Name As and the ActionScript from that frame will appear.

4.

Put a breakpoint at line number 4 by clicking the number 4. This stops the code from running when it reaches this point so we can see what is going on there.

5.

Click the Continue button to activate the login screen and put in the same login information as before. Then click LOGIN again. Now your debugger should look like Figure 17.7, with a little golden arrow in the red breakpoint you placed on line 4. This means that the code has stopped here.

Figure 17.7. The debugger is great for finding problems with variable values.


6.

Select the _level0 from the top left list, and select the Variables tab. You see that both variables are getting the correct information, but your conditional is looking for the variable pass not password.

7.

Go back into the authoring environment and change your code on line 4 from

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

to

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

and test again. Now when you attempt to log in, you see a message saying you have logged in correctly.

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.

1.

After you have debugger2.fla open, take a look at the ActionScript in frame 1 of the as layer. We create a text field at runtime and then set some text to it to label the image on the stage.

2.

Select Control, Debug Movie (Ctrl+Shift+Enter) to debug the movie. The debugger will appear as before, but this time we do not need to add any breakpoints, so click the Continue button to run the file. You can see the label now; it has a background, but no border, and it is in the wrong position.

3.

In the top-left list, select level0.label_txt and then select the Properties tab. Your debugger should look similar to Figure 17.8.

Figure 17.8. You can use the debugger to fine-tune the visuals of your file.


4.

The _x property needs to be set to 0, so double-click in the value field of the _x property, put "0" and press Enter. You will note on the stage that the field has moved over to the far left.

5.

Do the same to the _y property by setting it to 0 and pressing Enter; now the label is in the top left of the image, but it still needs a border.

6.

Select the Values tab and your debugger should look like Figure 17.9. Change the value of border from false to true and a thin border will appear around the label.

Figure 17.9. The Remote Debugging dialog box.


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.

1.

Select File, Publish Settings.

2.

In the Flash tab, select the Debugging Permitted option.

3.

Give your file a password of flashUnleashed.

4.

Click Publish. This will create both the SWF file and a SWD file needed for debugging.

5.

Post both of those files on a server, in the same directory.

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

1.

With Flash still open, select Window, Debugger.

2.

In the debugger's Options menu (at the top right of the debugger), select Enable Remote Debugging.

3.

Now, using a browser or the standalone Flash Player, map to the SWF you have put on the server. This should prompt the Remote Debugging dialog box, as shown in Figure 17.9.

4.

Leave the default selection of Localhost selected and click OK. This should prompt you for the password, as in Figure 17.10.

Figure 17.10. You can require a password for your file so that only those users you want can debug your file.


5.

Enter the correct password and click OK.

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




Macromedia Flash Professional 8 Unleashed
Macromedia Flash Professional 8 Unleashed
ISBN: 0672327619
EAN: 2147483647
Year: 2005
Pages: 319

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net