Getting Started: More on Xcode
Volume Number: 19 (2003)
Issue Number: 10
Column Tag: Programming
Getting Started
More on Xcode
by Dave Mark
Let's take the debugger for a spin. As we've done for the past few months, we'll work with the Sketch sample project. As a reminder, the Sketch files live in /Developer/Examples/AppKit/Sketch/. Launch Xcode and open the project Sketch.pbxproj.
Setting a BreakpointWorking with the Debugger
When the project window appears, click on the Project Symbols smart group (left side of the window in the Groups & Files list). When your symbols list appears, click in the search field (right side of toolbar) and search for the string init. As you learned last month, this will winnow the list of project symbols down to those containing the string init.
Figure 1 shows this list with the init in the file SKTGraphic.m selected. This is the file we're going to edit and debug. Double-click this line so an editing window appears, listing the contents of SKTGraphic.m.
Figure 1. Search the Project Symbols for files containing init.
Setting a Breakpoint
Scroll about one quarter of the way down the source file and click on line 178. As a reminder, the navigation bar is the strip immediately above the main editing pane. The line number follows the file name, which is immediately to the right of the navigation arrows (see Figure 2). Once you locate line 178, set a breakpoint by clicking in the left column, to the left of the line in the editing window. Take a look at Figure 2. Note that the breakpoint arrow appears to the left of line 178. This means that the debugger, once started, will stop execution just before it executes the if statement on line 178.
Figure 2. Line 178 is selected. Note the line number in the navigation bar and the breakpoint set on the left.
To start the debugger, click the Debug icon in the SKTGraphic.m editing window's toolbar. Depending on things like the speed of your machine, how much of the program is already compiled, etc., this may take a bit. Be patient.
Once your code is built, the Sketch app is launched. Click on the rectangle tool and drag out a rectangle. As you release the mouse button, the debugger will hit that breakpoint and bring the Debug window to the front. Figure 3 shows the Debug window when you hit the breakpoint.
Figure 3. TheDebug window, showing the program paused at a breakpoint. Note the display of Locals in the upper-right pane.
Take a look at the upper-right pane in Figure 3. Notice the display of variables. You can manipulate the column widths by dragging on the splits between the Variable, Value, and Summary column headers. I maximized the width of the Value column in Figure 3. You can click on the disclosure triangles to reveal fields within structs. For example, origin has an x and a y component. The origin line lists the values of all the origin fields. Open the triangle and each field gets its own line.
If you double-click on the x value, the value of x turns into a text editing field allowing you to modify the value of x. Just as you'd expect.
But if you double-click on the origin value (the one that lists x and y values separated by a comma), the origin formatter will appear in a text editing field. In this case, the formatting string is:
x=%x%, y=%y%%origin%, %size%
Double-click the size value column and the size formatter will appear:
width=%width%, height=%height%
Let's change the formatter. Change it to read:
w=%width%, h=%height%
When you finish the edit (hit enter), the change you made will propagate up through both the display of size and any other displays that reference size. To see this for yourself, click the Arguments triangle, then the self triangle, then the _bounds triangle to reveal origin and size within _bounds. On my display (see Figure 4), the _bounds value field is:
x=50, y=63, w=107, h=169
When we changed one size formatter, the change propagated to all fields that displayed a value of type size. Data formatters are tied to type definitions, which are global.
Figure 4. In this shot, notice that self._bounds.size uses the modified size formatter.
If you are unfamiliar with formatters, grab your favorite C text and do a bit of digging. Just like a formatter in a printf(), Xcode formatters allow you to specify how the debugger displays your variables. There's even an API so you can write your own formatters. See the Xcode release notes for more info.
Debug Controls
Figure 5 shows the debugger controls you'll find at the top of your Debug window. Chances are, if you've ever used a debugger before, you'll recognize most of them. Terminate terminates the process being debugged, Restart terminates the process and restarts it from the beginning. Pause pauses and Continue continues execution from the current stopping point. Step Over executes the next line of code without stepping into any functions, while Step Into steps to the next line of code, even if it means stepping into a function. Step Out completes the current function and stops immediately after the function's return in the calling function.
Figure 5. The debugger controls at the top of the Debug window.
The (in my opinion) coolest icon of the bunch, the Fix scotch tape dispenser is the equivalent of selecting Fix from the Debug menu. As I mentioned in last month's column, there appears to be a glitch with this icon in the Jaguar build of Xcode which I believe is fixed in the Panther build. Once Panther is officially released, I'll definitely be working exclusively with the Panther tools, so we'll get a sense of what's what in the current release of the tools.
The Breakpoints icon brings up the Breakpoints window (see Figure 6), which lists all your current breakpoints, organized by source file. You can turn breakpoints on and off using the checkbox associated with each breakpoint.
Figure 6. The Breakpoints window.
The Console Drawer icon opens a console drawer below the Debug window, allowing you to directly enter gdb commands. This is extremely cool, especially if you come from the Unix world and learned debugging using gdb, adb, or the equivalent.
You've got the gdb doc on your hard drive:
/Developer/Documentation/DeveloperTools/gdb/gdb/gdb_toc.html
Once More Into the Breach
Let's take one more spin through the debugger. If Sketch is currently debugging, click the Terminate icon. Now restart Sketch by clicking the Debug icon. When Sketch starts running, do not do anything in Sketch, just use the dock to return to Xcode. Back in Xcode, select Debug - ... from the Window menu to bring the Debug window to the front. Now, click on the Pause button to stop Sketch at whatever line was executing when you clicked the Pause button.
Figure 7 shows the event trace pane which is a stack showing the call sequence with main at the bottom and the current function at the top (in this case, the trap mach_msg_trap). Basically, this is what your app looks like when it is in an idle state, waiting for an event to happen.
Figure 7. The event trace pane shows call sequence stack.
Next, click the Continue icon to get Sketch back up and running. Back in Sketch, click on the rectangle tool and drag out a rectangle. When you let go, you should pop back into the debugger and your familiar breakpoint.
Click Step Into a few times until this line is highlighted:
temp = _bounds;
Remember, since this line is highlighted it has not yet executed. Click Step Into one more time. As you can see in Figure 8, when you execute this line and assign a value to temp, the temp fields displayed in the Value column are displayed in red, showing that they have changed.
If you click Step Into one more time, you'll change bounds. To see this change, you'll need to open the self triangle. self._bounds will turn red and temp will return to black.
Figure 8. When we change the value in temp, the temp fields turn red.
For our final trick, click on the Console Drawer icon. Scroll to the bottom of the window till you see this prompt:
(gdb)
At the prompt, type the command continue and hit return. This is exactly as if you had clicked the Continue icon in the toolbar. You are now back in Sketch and you can drag out some more shapes, as you like.
Till Next Month...
Whelp, I'm out of space again. <sigh>. There's so much more I want to talk about. Next month, we're going to take the debugger through its paces and we'll also play around with a feature called code completion, one of my very favorite parts of XcodeYou know, there are way more things I want to write about than there is space in the magazine. Note to self - see about adding more pages to mag. Ah, well. I've got a cool column idea for next month. Not sure I can pull it off. We'll See see. Look for you then...
Dave Mark is a long-time Mac developer and MacTech contributor. Author of more than a dozen books on various Mac-development topics, Dave is all about Xcode these days. Last month's column focused on the editor interface as well as fix-and-continue. This month's installment will take the debugger through a few of its paces, and explore Xcode's code completion feature.
