Debugging (Part Three)

Last time, we took our first look at the debugger in RB2005 and started exploring how to get around in it. Today, we're going to go a little deeper into the object viewer so that you have a better understanding of just how powerful a software debugger is.

Let's start out by getting a little more familar with the object viewer. Back in our scratch program, you've got a breakpoint set on the MsgBox line in the Foobar method (if you don't -- you should put one there now). When you run the application and click the button, you'll break into the debugger.

You'll see three items in the object viewer: Globals, s and self. As you can see, s is the "s as String" parameter passed into the Foobar method. Let's click the ellipsis button to view the properties of the string first. You'll notice that the object viewer tells you all sorts of interesting information about the string. For instance, it tells you that the string is in UTF-8, and for me, my string is 74 characters long, and also happens to be 74 bytes long. This character vs bytes distinction can be very useful when your string has multi-byte characters in it. For example, if you accidentally wrote code like this:
[rbcode]Dim mb as new MemoryBlock( Len( myString ) + 1 )
mb.CString( 0 ) = myString[/rbcode]
You could quickly determine why you're getting an OutOfBoundsException on the CString assignment by viewing the myString variable in the object viewer and noticing that the string is X characters long, but really X + n bytes long (which means you should be using the LenB function instead of Len). Another nice thing about the string viewer (aside: each object has a specific viewer in the object viewer. So when you hear things like the array viewer, or string viewer, what's really being referred to is the type of object being viewed) is that you're able to see the entire contents of the string. Since my string is 74 characters long, that's quite large to be showing in a single line in the object viewer. But the string viewer shows me a multiline EditField's worth of data, which is sufficient to view the entire string.

Now that you've seen the string viewer, let's see the generic class viewer. You should get extremely comfortable with this viewer since it's easily one of the most common viewers used in the debugger. Click on the view switcher, and bring yourself back to the Variables view. Then click on the self as Window1 variable in the view. Remember, self is one of the implicit variables in any method or event -- and the debugger is smart enough to show only self right now since self and me reference the same window object (in fact, if you use the stack viewer to switch to the PushButton1.Action event, you'll notice that me and self are both displayed for you since they reference different objects).

You should now be seeing something like this:

What you're seeing are all the properties of the Window1 object instance. You're seeing things like a color viewer for the Backdrop property (with the color swatch on the right-hand side of the pane), as well as other basic data type viewers (integers, boolean, strings, etc). There are also links to other object viewers, like the Graphics or MenuBar properties.

Time to learn cool new trick number one. Right-click on the Handle property value, and you'll notice a contextual menu is displayed. In RB2005, you're able to switch the numerical view of integer properties to whatever context is easiest. Since this is an OS handle integer, select "View as Hex" from the list, and you'll now be viewing the Handle property as a hexidecimal number. Even cooler still, the debugger remembers your preference, so if you switch back to the variables view, then select the window again, it'll continue to be displayed in hexidecimal.

Now you can learn another cool trick with the debugger -- do you see the hyperlink at the top of the window's property list that says "Contents?" That is the list of the contents of the window object -- anything you've dropped onto the window will appear in that list. If you click on that hyperlink, you'll notice that the PushButton that we dropped onto the window is listed. Selecting PushButton1 from the list will now display all the properties of that button's instance. In this fashion, you can quickly see the state of anything on the window -- the window properties, content properties, etc.

But let's modify our scratch program slightly to demonstrate the power of this. Stop the debugger, and now make a new property on the window called mAwesome as Integer, and make it private. Then, in the PushButton1's action event, put the following code at the very top of the event:[rbcode]
mAwesome = rnd * 100[/rbcode]
Now run the project again and click the button. You'll notice now that when you view the self object's properties, that mAwesome is listed (between MacWindowPtr and MaxHeight) and it displays the property's value. The debugger will display all the properties of objects -- not just intrinsic ones, but ones that you've added as well. So you can really see the complete state information about an object at the drop of a hat. Neat eh?

Stay tuned -- next time, we'll continue our dive into the debugger. But as you can already see, a software debugger is a very powerful utility for seeing the state of your application.