Foundation Game Design with ActionScript 3.0, Second Edition (11 page)

Figure 1-36.
Collapse blocks of code you're not currently working on if you want to de-clutter your editing window.

If you're working on a complex program and want to test only part of it, not the whole thing, you can add a
breakpoint
to your code. When you add a breakpoint, the code will stop running at that point. This is very useful if you know you have an error further down the line, but just want to test your code up to the point where you know it's working.

Unfortunately, it's also very easy to accidentally add breakpoints to your code if you double click on the left margin without thinking about it. As a beginner, you won't know the breakpoints are there. You'll just notice that your program won't run properly. You won't get any errors, but the program will just seem to stop part way. If this happens to you, check to make sure that you haven't added any accidental breakpoints, and delete them if you have.

You add a breakpoint to your code by double-clicking on the left margin of the editing window. You'll see a tiny blue circle appear, as shown in
Figure 1-37

Figure 1-37.
Adding breakpoints to your code will stop it from running after this point. This is useful for checking to see which parts of your code are working and which aren't.

When you've added that breakpoint, your code will stop at that point when you run and debug it. That means that it won't run the trace statement that follows, and you'll see nothing in the Console window except a message that the SWF file was created.

You can remove the breakpoint by double-clicking on it again. After you do this, run and debug your program again, and the program should run to completion just fine.

However, sometimes you'll want to use breakpoints to check which sections of your code are working and which aren't. In that case, leave a breakpoint in place, and open the Breakpoint view window. You can make the Breakpoint view visible by selecting Run
Debug
Other. A new Show View window will open. Open the Debug folder and select Breakpoints, and click the OK button, as shown in
Figure 1-38
.

Figure 1-38.
Display the Breakpoint view window to help manage your breakpoints.

You'll now see a new Breakpoints window at the bottom of Flash Builder's workspace, as shown in
Figure 1-39
. It will show you all the breakpoints in your code.

Figure 1-39.
Display the Breakpoints window to see where the breakpoints are in your code.

The Breakpoints window comes with its own menu bar at the top right. You can deactivate a breakpoint by unchecking it. If you double-click on a breakpoint, the cursor in the code editing window will jump to the spot where you added it. You can remove breakpoints by selecting them and clicking the X button in the menu bar. Many of these same options are available from Flash Builder's Run menu.

If you run and debug your code with a breakpoint and want to see what will happen if your code continues from that point, you can select Resume from the Project menu, as shown in
Figure 1-40
.

Figure 1-40.
Resuming from a breakpoint shows you what will happen if your code runs from that point onward.

From the same Run menu, you can also
step over
a breakpoint. This is useful if you set a breakpoint on a line that you think contains an error and want to test your program without having that line run. It omits the suspect line from your program and shows you how your program will run without it.

There are some more advanced features of breakpoints, such as setting them to run conditionally, and you can find out more about them in the chapter “Debugging Tools in Flash Builder” in Adobe's Flash Builder documentation at

When you start writing long, complex programs, you'll gradually appreciate how useful breakpoints can be to help you test and to isolate the parts of your code that are working from the parts that aren't. Breakpoints are an essential debugging tool.

Flash Builder has a feature called
Perspectives
that changes the way that windows are organized in the workspace. If you've just installed and started working with Flash Builder, you're probably using the perspective called
Flash
. The Flash perspective arranges the workspace in the way that I've described it in this book, with the Package Explorer and Outline window to the left of the editing window and the Console and Problems windows at the bottom.

There's no reason to change this perspective, but it's important to know that you can if you want to. And there's also a chance that in your exploration of Flash Builder you may have accidentally switched the perspective and you can't get back to the standard Flash perspective I've been describing.

The top right corner of Flash Builder's toolbar has buttons that let you switch perspective, as shown in
Figure 1-41
.

Figure 1-41.
Change the way windows are organized in Flash Builder's workspace by switching the perspective.

The perspective that is currently selected will be indicated by the depressed button.
Figure 1-40
shows that the Flash workspace is currently selected. What happens if you select the Flash Debug perspective?
Figure 1-42
shows what it looks like.

Figure 1-42.
The Flash Debug perspective

All the windows that are used for solving problems and debugging your program are in a useful arrangement and easily accessible. The Breakpoints window is at the top right, in addition to two new windows, Variables and Expressions.

There are many other perspectives included with Flash Builder, and you can find them all by clicking on the Open Perspective button and the clicking Other, as shown in
Figure 1-43
.