Learning More About the Debugger | Adobe Flex 2: Training from the Source

So far in this book you've used the debugger built into Flex Builder in a limited way on a number of occasions. In this task, you will learn more about the debugger and how it can help you find errors in your application and more fully understand your application.

Learning More Details About Setting Breakpoints

In earlier lessons, you created breakpoints by double-clicking in the marker bar (next to the line numbers in an editor) to toggle breakpoints on and off. Here are more details about creating breakpoints:

Youcan add breakpoints only on executable lines of ActionScript code. This means you can set breakpoints on lines that contain the following:
- MXML tags that contain an event handler. For example,
```
<mx:Button click="clickHandler()"/> 
```
- ActionScript code enclosed in an <mx:Script> block.
- Executable ActionScript in an ActionScript file.
If you set a breakpoint on a line that does not meet one of the listed criteria, Flex Builder will automatically scan down 10 lines to try and find a valid line to place a breakpoint. If it does, the breakpoint will be moved. If it cannot find a valid line for a breakpoint within 10 lines, the breakpoint will be ignored when debugging.
The moving of the breakpoints will happen when you start your debugging session; if you set another breakpoint during a debugging session, it will be moved immediately.
After you hit a breakpoint and are in Flex Builder in the Flex Debugging perspective, you have a number of options for controlling application flow and breakpoint manipulation. On top of the Debug view, you see options for controlling your debugging session.

Here are the most common commands:

Resume Resumes execution of an application that has been interrupted by a debugging session. You can either run the application to completion or to another breakpoint set in the editor.
Terminate Stops the debugging session.
Step Into Steps into the called function and stops at the first line of the function.
Step Over Executes the current line of the function and then stops at the next line of the function.
Step Return Continues execution until the current function has returned to its caller or until another breakpoint is reached.

Inspecting Variables and Their Associated Values in the Debugger

After you have hit a breakpoint, you have a number of ways to inspect values of variables at the current state of the application. In a previous lesson, you used the Variables view to check the value of a variable. In the Variables view, you can check the values of the current object context, located in the this variable. If you happen to be in a function, you can also check the variables defined in that function by inspecting the variables labeled with an L in the circle in front of the variable. The following figure shows a debugging session stopped in an event handler where the event is passed to the function as a parameter, and hence scoped local to the function.

In the Variables view, there can be hundreds of variables to inspect. There is a feature in Flex Builder to help you find a variable from that long list: the Find Variable option. You can use either Ctrl+F or right-click in the Variables view and select Find Variable to bring up the interface. As you type in the data-entry section, the variables matching your entry will be listed. You can then click on the variable you want to be highlighted in the Variables view.

If you are watching one variable or a small set of variables, a better option is to use the Expressions view. In the Expressions view, you can enter variables (or expressions) to watch; when debugging, the values of the variables will then appear in the Expressions view. You don't have to search for them in a long list of values in the Variables view.

From the FlexGrocer project, open DataEntry.mxml. Locate the unitRPCResult() event handler, which is called when the HTTPService successfully returns unit information. Place a breakpoint on the line of code that assigns the unit variable a value from the event object by double-clicking in the gray column to the left of the line numbers.

Debug the DataEntry.mxml application. Be sure that you are viewing the Flex Debugging perspective in Flex Builder.

You will either be automatically taken back to Flex Builder after you debug the application, or else you might have to click the blinking Flex Builder icon in the Task Manager to get back to Flex Builder. If you are prompted to go into the Flex Debugging perspective, click OK.

Assume that you want to check the value of the units variable to be sure that the values are properly assigned. The first thing to do is to be sure that the event object contains the correct data. Use the Variables view and drill into the event object to see that the data is returned correctly.

In this case, the path to the XML data returned by the HTTPService is event

result

allUnits

object

unit. There you see the ArrayCollection returned.

Now you know that the data is being retrieved correctly. Next, you want to be sure it is assigned to the units variable. Click the Expressions view tab and then right-click in the Expressions view and select Add Watch Expression. Enter units and then click OK. Notice that the variable is defined because it is declared as an ArrayCollection in the application. Drill down into the variable; you will see it does not have any values.

The reason why the units variable has no values yet is because the breakpoint stops execution before the line is executed. So you must run the line of code before the assignment is made.

In the Debug view, click the Step Over button; you will see that the debugging session is now sitting on the closing brace of the function and that units now has the correct values.

Note

Do not terminate the debugging session because you will shortly see that you can add breakpoints during an active debugging session.

Now assume that you want to be sure the data returned from the Data Manager is also correct, which retrieves data for the variables categories and foodColl. Place a breakpoint on the closing brace of the categorizedProductDataLoaded() method.

Be sure that you have not terminated the debugging session and then click the Resume command. You will see that the debugging session has now highlighted where you set the second breakpoint. Double-click the Variables tab to make it full screen.

Because there are so many properties in the Variables view, it is often helpful to make it full screen when looking for variables and their associated values.

In the Variables view, be sure to expand the variable to see all the variables within the scope. Right-click in the Variables view and select Find Variable. Start typing categories until you can see that variable highlighted in the Variables view. Click OK to close the Find Variable window, and then check to be sure the correct data stored in an ArrayCollection is in categories. Right-click in the Variables view again and select Find Variable. Start typing foodColl until you can see that variable highlighted in the Variables view. Click OK to close the Find Variable window and then ensure that the correct XML data is in foodColl.

Notice that you can see the values of the variable selected in the Variables view in the Detail Pane. When you select foodColl, you can see the actual XML in the Detail Paneeither to the right of or below the variable display.

You can change the location of the Detail Pane by choosing the option from the Variables view menu (a downward-facing triangle) and selecting the Orientation option of your choice.

Be sure you are still in a debugging session, and assume that you want to be sure that correct data is being returned from a component that updates a product. Set a third breakpoint on the first line of code in the updateProduct() function.

This breakpoint will behave a bit differently from the second one you set. When you resumed the application to continue to the second breakpoint, you did not have to interact with the application, loading data happened on startup. When you resume, you will have to interact with the application for the third breakpoint to be hit.

10.

Select the Resume command from the Debug view. Return to the browser where the application is running and select a product from the Tree on the Update/Delete Product tab. Make a change to the product information and then click Update. Be sure that you are viewing the Flex Debugging perspective in Flex Builder. In the Variables view, check to be sure that Product has your new value.

Tip

Of course you could have terminated the debugging session, cleared the first two breakpoints, and then set a single breakpoint on the updateProduct() function. But by following that procedure, you would not have seen that you can select Resume, return to the application and get to the next breakpoint in a single debugging session.

11.

Terminate the debugging session and close any open files.

You will be working with a different main application in the next task.