Adobe Flex Builder 3 Links:

- Try Flex Builder 3

- Upgrade to Flex Builder 3

- Buy Flex Builder 3

- See upgrade details

- More purchase options

Inevitably, the process of coding your Flex applications will sooner or later result in some bugs. As a continuation of our coverage of the Flex Builder I.D.E., we focus this time on the built-in debugger tool, and a few of its capabilities. Those new to Flex programming should take away from this a basic understanding of how to use debugging as a means to pinpoint any problems in their code.

In order to use the debugger in Flex Builder, you'll need to have the debug version of Flash Player installed. This is because a Flex debugging session produces a special swf file that contains extra information relevant to the debugging process. The debug version comes with your Flex Builder installation, so if you find that you have the wrong version installed for some reason, you can simply navigate to your Flex Builder or Flex Builder plugin directory, and you'll find the correct version of Flash Player in a folder called "Player". Reinstall, and you should be ready to go.

In Flex Builder, your debugging session is carried out within the "Flex Debugging" perspective. The easiest way to get to this perspective is to locate the "Open Perspective" control in the top right corner of the workbench. Clicking on the little "square" icon with the "plus" sign gives you a drop-down menu of the different available Perspectives.

One thing you may notice right away is that the code editing window is a lot smaller in the Debugging perspective than it is in the Development perspective. Taking up some of that space are a few new windows unique to debugging. Up top, the "Debug" window contains some controls that we'll be using later that allow us to run our application line by line. To the right, the "Variables", "Breakpoints", and "Expressions" views are contained within a shared window. These will hold information of interest to us as we begin to debug our application. And down at the bottom, we have a window that contains a "Problems" view, and a "Console" view. Notice also, that by default, there is no "Outline" view.

This arrangement may be the default setup, but you still have the ability to re-size and rearrange the windows of your workbench, just as when working in the Development perspective. Launching an application in debug mode is as simple as clicking on the "bug-shaped" button control on the toolbar.

Your debugging session will be running until you do one of the following:

1. Close your browser window.

2. Stop the debug session within Flex Builder in either of two locations:

You can only run one debugging session at a time, so it's important to remember to close your session before attempting to start another. If you do start a new debugging session without closing the first session, your first session will no longer be a debug session, but the application will continue to run.

To use as an example, I've loaded the Calculator application that we've visited previously in Learning Flex From Scratch. The source code is available here.

To get started with our debugging session, let's first explore the use of trace statements. A trace statement is simply an expression displayed as a String in the Debugging perspective's console window. You get a trace statement by including a trace function within a code block of your ActionScript, and then running your application in debug mode. For example, the following trace function:

trace ("I'm a trace statement");

would produce a literal String with a value of "I'm a trace statement" in the console window when your application's execution has reached (and executed through) the particular line of code that contained the trace function.

A trace function can contain multiple arguments, all of which are expressed as Strings. For example, in the code block of the calculator's event handler function, there's a trace statement that produces both a literal String, as well as the value of display.text:

trace( "Button click: " + (display.text));

So then, when we run the Calculator application in debug mode, perform a calculation, and then revisit Flex Builder, our console window should display "Button click" and the value of display.text. Performing the calculation "1+2 =3" gives us the following trace statement:

Button Click1 "Button Click" + value of display.text after clicking the "1" button.

Button Click2 "Button Click" + value of display.text after clicking the "2" button.

(No "3" is listed because our trace function isn't within the block of code that defines the behavior of the "=" sign.)

As you might imagine, trace statements can be useful in a variety of ways. You could, for example, simply insert trace functions in various parts of your application's ActionScript to produce literal Strings, allowing you to monitor your application's order of execution. Likewise, you can also use trace statements to monitor more complex processes within your application's execution by including arguments in the trace function, as we did in the very basic example above.

Here's another example of how we can use trace statements. Say we wanted to monitor which particular operations occur whenever we run our application. In the Calculator example, we can include trace functions that will tell us what kind of operation just occurred, (i.e. adding, subtracting, etc). I've included trace functions within the code blocks of the conditional statements that set the value of display.text after "=" clicked. For example:

 
if (myOperator == "x")
{
     trace ("I'm Multiplying!");
     result = (firstEntry * secondEntry);
     display.text= result.toString();
}

Running our application in debug mode, and performing the following operation "2 X 3 = 6", will give us these trace statements:

Some of you may still be wondering, "but where is the "6"? After all, display.text gets a value of "6" when we complete this calculation, so what gives? Again, the trace function that produces the value of display.text was placed outside of the code block that defines the behavior of the "=" Button, so our trace statements don't reflect any of the logic found within that block. We can use another tool within the Flex debugging environment to find out which block of code is responsible for producing the result of our calculations.

Breakpoints are a handy feature in the debugging perspective that allow you to pause your application's deployment anywhere you like. You can easily place a breakpoint anywhere in your code by simply double-clicking on the line number that you wish to stop on. Your application will run through its code up to the breakpoint, and then you can use controls in the Debugging Perspective to step through subsequent blocks of code to see how this changes various parameters.

In the Calculator application, at the beginning of the ActionScript code, I put a breakpoint on the first line of the clickHandler function.

This breakpoint will cause the application to pause every time a Button is clicked. Because of this, entering a calculation such as "2X3=6" in debug mode will require some extra steps.

Launch the application in debug mode, click on the "2" Button, and return to Flex Builder while still in debug mode. At this point, some additional controls in the "Debug" window become available, and the line at which the application paused becomes highlighted.

Our application has paused, but we can continue our "2X3=6" calculation by clicking on the "play" control in the Debug window's toolbar.

Switching back to the running application in your browser, we can click a button, but then once again this pauses our application as it runs into the breakpoint. Run through this process a few more times, and we get to our final result of "6".

Through every iteration of our debug "pause/play" session, we can monitor the changing values of our application's variables. Up at the top of the screen, adjacent to the Debug window, we have a window that displays information pertaining to Variables, Breakpoints, and Expressions.

Let's run the calculator one more time, pausing and playing throughout the steps of the calculation. After the first entry of "2", our Variables window has this on display: (I've expanded the Variables window display for easier viewing).

We're focusing on the value of "display.text", which is within the scope of "this/display/text". Our application has paused on, and not executed through, the code that assigns a value to display.text, so it currently has no value.

Hit "play" and click on "X". The application is paused. Returning to the Variables window, we see that because we've now made it through the code that sets display.text to "2", we see that the value of the variable (display.text) has indeed changed:

Hit "play" again, click on "3". Again, the application is paused. Hit "play", and then click "=". Return to the debugging perspective and see that now the Variables window is displaying this data:

Again, we've clicked on the "=" Button, but haven't yet executed the code necessary to actually display the result of our calculation. We could simply do what we've been doing and hit "play" again. We'd have to click another button though, to run the clickHandler function. Now might be a good time to bring up another very useful debugging technique - stepping through your application's code line by line.

In the Debug window, there are a few controls that you can use to navigate through your code:

The three yellow arrow controls are from left to right, "step into", "step over", and "step return", respectively. We'll be using the middle "step over" control in this example. With our breakpoint set on the first line of the clickHandler, and having gone through a number of "play/pause" cycles until we were able to click the "=" Button, we'll now step through our code to find out what part of the application is responsible for setting the value of display.text after "=" has been clicked.

Using the "step over" control, we can see that the highlighted section of code moves down through our application with every click of the control. Keeping an eye on the value of display.text in the Variables window, we see that our value changes to "6" when we get through this block of code:

 
if (myOperator == "x")
{
     trace ("I'm Multiplying!");
     result = (firstEntry * secondEntry);
     display.text= result.toString();
}

This is, of course, a simple example, but it illustrates how useful breakpoints can be for monitoring the changing value of variables as your application executes.

You can also use breakpoints to pinpoint logical errors in your application's code. If you've accidentally coded a syntax error, Flex Builder's "Problems" window will let you know about it. However, if you have inadvertently coded something that does compile, and yet still doesn't do what it's supposed to, you can use breakpoints to help you figure out what's going on.

In the above example, we used a breakpoint to find out which block of code changed display.text's value. It's likely though, since you created the code in the first place, you probably already know what code block does what in your own application. In this case, we can put a breakpoint on the misbehaving block of code to try and resolve a logical error.

After stepping through the block of code, we can see that executing our code block gave us a display.text value of "5", and not the desired "6". A quick glance at our code, and it's obvious that the error lies in the use of the "+" operator instead of the "*" operator. Change the code to read:

result = (firstEntry*secondEntry);

and the problem is solved.

Again, this is a simple example, but it hopefully illustrates another way to use debugging to pinpoint problems within your application's code.

Like most of the topics covered in the Learning Flex From Scratch series, what we've covered is merely an introduction. Indeed, Flex Builder provides developers with many more advanced debugging features than were mentioned here. For those interested in exploring debugging further, we've collected a few helpful links to get you started.

10 Flex debugging tools

http://www.flex888.com/656/10-flex-frameworks-and-debugging-tools.html

Livedocs

http://livedocs.adobe.com/flex/3/html/index.html

RIAdobe's List

http://saravananrk.wordpress.com/2008/03/31/the-list-of-helpful-flex-or-flash-debug-tools/

Read more from Adam Flater & Scott Sheridan.