Debugging (Part Two)

Last time we started discussing the various methods of debugging your application as well as some basic definitions that we'll be using throughout the series. Today we're going to get started on debugging our very first application.

So that everyone can be on the same page with this discussion, we're going to create a scratch program that we will be using as an example. So fire up your copy of REALbasic 2005r3 -- you should now be staring at a new, blank project.

Open up Window1, add a PushButton to the window. Double click the PushButton, and in its Action event, put the following code:
[rbcode]
Dim i as Integer = 12
Dim s as String

s = System.CommandLine

Foobar( s )
[/rbcode]
Then make a new Method, name it Foobar, and have it take s as String as its only parameter. In the new method, put the code [rbcode]
MsgBox s[/rbcode]
Now we've got a very simple scratch program, so we can begin our foray into the debugger.

The first thing I want you to do is to put the cursor in the Foobar method of the code editor, on the MsgBox line. Then go up to Project->Turn Breakpoint On (or hit Ctrl+\) -- you should see the little red dot we talked about last time. If you click it, you'll notice it disappear; click again and it reappears.

Now, hit the Run toolbar button (or go to Project->Run, or hit Ctrl+R). The application will compile, and eventually launch. Now, click the PushButton on the window.

At this point, you should have broken into the debugger window. Let's familiarize ourselves with this window before we go any further. You should see something akin to this:

I drew some numbers on the image so that I can direct your attention to some of the main areas in the debugger.

#1 is what's called the code viewer. It looks a lot like a source code editor, except you're not allowed to edit code in it. This part of the debugger shows you the code that's currently being executed. You'll notice that the line "MsgBox s" has a grey border around it -- that's the line which is about to be executed.

#2 is called the object viewer, and as the name implies, it allows you to view various objects. For example, the objects you are currently seeing are all the local variables currently in scope. "s" is the String parameter passed into the Foobar method, and "self" is the Window1 context. You'll notice that "me" isn't listed -- that's because "me" and "self" refer to the same object in this context. Anything that's blue and underlined in the object view is a hyperlink that you can click on. When you click on a hyperlink, the object viewer switches to a new view of information about that object. The button with the ellipsis in it is for displayinga new object viewer which displays more information. For example, if you click on the button on the "s" variable's line, you'll see a dialog which displays information about "s" such as its length, its encoding, and a more full display of the string. This brings us to...

#3 is the view switcher, which lets you change the contents of the object viewer. As you follow links to dive down deeper into various objects, the view switcher is how you get back up a level (or more) to a previous view. So if you're done viewing the string's contents and you want to go see the local variables again, you can click on the view switcher and select Variables to be brought back to your original view.

#4 is the stack viewer, which allows you to traverse the stack by selecting items from the PopupMenu. The code which is currently being viewed corresponds to the method or event name currently listed in the stack viewer. So you'll notice that we're viewing the Foobar method, but if you click on the stack viewer, you can see that we were called from the PushButton1.Action event. You'll also see the familar grey highlight in the code viewer -- this is showing you what line caused the method execution.

Finally, #5 is the default toolbar, which is showing you the most common debugging options. You can do things like stop debugging, do the various step operations, or even edit your code for the currently viewed source. Note that if you edit the code, you must recompile the application and restart debugging for the new code to take effect.

Phew! I think that's plenty of information to absorb for today. Hit the Stop toolbar button to stop debugging. We'll pick up next time with exploring the debugger a little bit deeper.