Debugging for Kicks

While showing how to display an alert helps in learning how events can work, displaying such a pop-up alert with every little change can be annoying. Because this isn’t really a feature you’d want to implement in your application, but more of a way for you to learn from and test your application, there’s a better way to display information in regard to an event. It’s called debugging. While the name implies that there’s a bug, or glitch, in your software that you’re trying to locate, you’ll see there’s really more to debugging than that. Debugging in Flex is a great way to show the innards of your application or to display information while you’re developing.

Outputting Information to the Console

To debug your application, you’ll use a method called trace() that will display some text in the Console panel. Simply replace the Alert.show method with trace, as in the following:

                    
public function showInfo():void

{
 
 trace("Your name is " + fullNameTextInput.text + 
 
 " and your age is " + ageNS.value);
 
}

Now, just running the application won’t actually display this information. To use trace, you’ll have to be debugging your application. How do you do that? Pretty easily—I’m glad you asked. Instead of running the application by using the green arrow button, you’ll click the green bug icon to its right. Clicking this icon launches the application in debug mode. In most cases, it will look the same to you, but now when you change the NumericStepper, the string of text will be output to the Console panel.

Note: The Console panel is, by default, located at the bottom of your Flex Builder window, next to the Problems panel. If your Console panel isn’t visible, make it visible by selecting Window→Console.

Debug your application, click the NumericStepper a few times, and then switch back to Flex Builder to see the information in the Console panel. The same information that was previously in a pop-up alert is now output to a new line of text in the Console panel, as shown in Figure 6-5.

Figure 6-5. The output of a trace in the Console panel

The trace statement is deceptively simple. However, coupled with debug mode, it will be one of your most powerful tools as you grow as a developer. Next you’ll learn how to use debugging to find out more information about an event.

Using Event Parameters in Debugging

Remember those parameters you learned about that you could pass to a function? You’ll now add a parameter to your showInfo() function called event and make it of type Event. (You could call it whatever you like, but I usually just call it event in lowercase.) Now in the trace statement, you’ll be able to get some details about the event, namely, two properties called type and currentTarget. Your function should look like this:

                    
public function showInfo(event:Event):void

{
 
 trace("The type is " + event.type + 
 
 " and the current target is " + event.currentTarget);
 
}

What’s going to happen is an event object will be passed to this function. It is of type Event, which is a general type that has properties attached to it which are helpful in learning about the event. The type property contains the name of the event type, which in this case is a change event (“change”). The currentTarget property contains a reference to the object that passed the event, which is whatever called the function.

You might have realized that making this work requires one more step: you have to actually pass the parameter to the function when you call it. There’s a special parameter in Flex called event that is used to pass event objects to functions, and you’re going to use it. It’s built in. You haven’t created any variable called event, but Flex will create one at compile time. Think of it as a feature. Pass in the event by using the following code for your change event on the NumericStepper:

                    
change="showInfo(event)"

And pass in the event for the button by using this for your click event on the button:

click="showInfo(event)"

Because the function expects an event parameter to be passed in, failing to pass it when calling the function results in a compile-time error.

Now when you debug the application and change the NumericStepper, you’ll get a message in the Console panel like “The type is change, and the current target is HelloWorld0.panel.ageNS.” Make sense? You knew the type of the event would be change, but that current target value is a little cryptic. Notice the ageNS, which is the id of the NumericStepper. But what’s the HelloWorld0.panel part? Well, when Flex creates your application, it actually creates a class based on the name of the application. In this case, Flex added zero to the end of the name. As for the .panel part, that’s the id of the panel in which the NumericStepper is located. So, in terms of a hierarchy, ageNS is considered part of panel, which is in turn part of the HelloWorld application.

When clicking the button, the trace statement will display slightly different information. Because the event registered on the button is a click event, the trace will display the event type as “click.” Also, you’ll see that the currentTarget is the button. (If you haven’t given the button an id, the Flex compiler creates one for you, and it may be displayed here as “Button0” or “Button23” or something like that.)

This event information is handy when creating functions, because you can make the functions highly reusable. You could create one function that changes what it does based on who called it (the currentTarget) or what type of event occurred (the Event type).

Using Breakpoints

Next you’ll learn a pretty advanced technique, but it’s one I find so essential that it merits explaining. I’m talking about using breakpoints in your code to really see what’s happening.

A breakpoint is a place in the logic of your code at which you’d like to stop everything. Because some programming constructs can get complicated, it’s really useful to be able to say, “Hold up a minute!” and check how things are going. A breakpoint allows you to do that, letting you pause the application and view its current status before continuing.

To use a breakpoint, double-click in the gutter, the area where the line numbers appear to the left of your code. Do this next to the line of code in which you want to create a breakpoint. In this case, you’ll want to create a breakpoint in the only place it makes sense, the only place you really have application logic, within your one and only function. So, place a breakpoint to the left of your trace statement, as shown in Figure 6-6.

Figure 6-6. A breakpoint placed on line 11

Now when you debug the application, whenever the NumericStepper is changed or the button is clicked, the function will be called and the breakpoint will be set. You’ll probably be prompted the first time with a dialog box from Flex Builder similar to Figure 6-7, which asks you whether you’d like to switch to the Flex Debugging perspective. I recommend turning on the checkbox that says “Remember my decision” because this will launch the right perspective when breakpoints are set. Click the Yes button, and you’ll have a whole new perspective.

Figure 6-7. Confirm Perspective Switch dialog box

Seeing a New Perspective

Perspectives in Flex Builder are just a way of specifying and remembering a panel layout. When you’re developing in Flex Builder for the first time, you’re using the Flex Development perspective, which contains panels like Flex Properties and Flex Navigator. When debugging, you’ll be using a few new panels specific to that task, and they’re contained in the Flex Debugging perspective.

One of these new panels you’ll see, now that you’re in the Debugging perspective, is the Variables panel. By default it’s located in the top right of Flex Builder. Flex Builder also allows you to move and resize panels easily just by clicking and dragging the title bar of the individual panel. Because this panel is a tree list that needs a lot of vertical space, I really recommend moving it so that it takes up the whole right side of Flex Builder. Just click and drag the panel, moving your mouse to the far right side of the Flex Builder window. You’ll see a thin #CCCCCC outline, which is your feedback as to where the panel will be placed. You can also drag the panel outside the Flex Builder window, and it will be placed in its own pop-up window.

Whether you clicked the button or changed the NumericStepper, the Variables panel will display information about your application in its current state, at the breakpoint you set. You should see two items in a tree list, one called this and another called event. The item this refers to the application as a whole, and the item event refers to the event parameter that you passed to the function.

Click the arrow to the left of the event item to display the child nodes. You’ll focus on the items in the [inherited] node, so click the arrow to display them. You’ll see all the properties of this event object, including the beloved type and currentTarget properties, displayed with their current values, as shown in Figure 6-8.

Figure 6-8. Variables panel

Ending Your Debug Session

Feel free to poke around here as you wish. You might want to return to this later, because it will tell you a lot about how Flex works, so keep it in mind. For now, close this perspective, and end your debug session. Note that debugging may lock up your browser, because it pauses Flash Player. So, the way to end the session is by clicking the red, square button located both in the Console panel and in the Debug panel, as shown in Figure 6-9. You can also access this command by selecting Run→Terminate. That will terminate the debugging session. When you’re done, you’ll also want to return to the Flex Development perspective by using the toggle button bar at the top right of Flex Builder or by selecting Window→Perspective→Flex Development.

Figure 6-9. Debug panel

Summary

Now you’ve learned a bit more about what events are and how to use them in your application. Don’t worry if some of this is overwhelming; interactivity can be a very challenging part of development. If you need to return to this chapter later for a refresher, feel free. While your application may not be looking that different yet, you’ve learned some very important concepts in creating interactivity that you’ll be able to use very soon.

In the next chapter, you’ll get into some of the powerful features of Flex. Then you’ll really start to make your application into something useful.