Volume Number: 19 (2003)
Issue Number: 4
Column Tag: Getting Started
by Dave Mark
In this month's column, we're going to explore some of Project Builder's nooks and crannies. The column started on a completely different tack, when I found myself trying to find the definition for a specific class function. I dug through the /Developer/Documentation/ directory, which is absolutely worth doing, but there's a lot of doc there.
I went on line to ask some of my Project Builder buddies how they would go about solving this particular problem and got a bunch of different responses, all of which led to the same end, and each of which taught me something new about Project Builder. This month, I'd like to share what I've learned with you.
Let's start off by creating a new project, called CrannyTester. Launch Project Builder, select New Project... from the File menu, scroll down to the bottom of the New Project window and create a Foundation Tool project. Name the project CrannyTester.
One Window, Some, or Many?
One Project Builder feature I really like is the ability to customize PB's use of windows. Select Preferences... from the Project Builder menu, then click on the Task Templates icon at the top of the prefs window. Now click on the Basic Settings tab (Figure 1).
Figure 1. The window template settings in the Preferences... dialog.
As you can see, there are four basic window setups. Single Window forces the entire Project Builder interface into a single swiss-army-knife of an interface, a single window filled with tabbed panes (Figure 2). If you are working on a laptop or on a smaller monitor, this is a very efficient way to go.
Figure 2. The CrannyTester project in Single Window mode.
One bit of funkiness to be aware of: When you change selections in the Task Templates preference panes, your changes won't take effect until you open a new window. To get the change to affect your current project, make the change, then close your project and reopen it.
To see this for yourself, set the preference to Single Window, then open a project or create a new one. A set of horizontal tabs (similar to the Find/Build/Run/Debug/CVS tags in Figure 2) will appear in the window.
Now go into preferences and change to Some Windows. Even if you click the Apply button, the tabs will still be visible. Now close the project and reopen it. The tabs disappear as the Some Windows preference is applied.
Chances are, you'll pick a mode you like, then create all your projects in that mode. If you do find yourself playing with the windowing modes, be sure to reopen the project to see the effect properly.
"Some Windows" adds separate windows for Find, Build and Debug. "Many Windows" opens everything in its own window and feels most like CodeWarrior to me. I spend most of my time in Some Windows but love the flexibility of switching to Single Window when I'm on the road. Sweet!
Now that you've got your project setup the way you like it, I'd like to share another Project Builder nook with you. Or maybe it's a cranny. Hmmm.
Open the CrannyTester project you created at the beginning of this month's column. Click on the Files tab, open the Source triangle, and click on the source file main.m. Here's the source code you should see:
#import <Foundation/Foundation.h>
int main (int argc, const char * argv[]) {
NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
// insert code here...
NSLog(@"Hello, World!");
[pool release];
return 0;
}
This is the default source for a Foundation Tool and should look reasonably familiar to you. One of the keys to understanding any new framework is the ability to find descriptions of the classes and utility functions that you encounter in the framework's documentation. One thing Apple's dev tools have no shortage of is documentation. While I do recommend that you spend some time prowling through the /Developer/Documentation/ subdirectories, there are some clever little shortcuts built into Project Builder that will bring you right to the pages you are looking for.
Let's start with the most obvious path. If you click on the Classes tab, you'll see a list of classes in the upper pane, with a list (empty, right now) of members in the lower pane. Below that is a popup menu that should be set to "Heirarchy, all classes" with an Options button to its right (See Figure 3.)
Figure 3. The Classes tab, with its list of classes.
Lets say you wanted to read up on the NSObject class (and you should). NSObject is the root of most of the classes you'll use to develop your Cocoa applications. Click on NSObject in the Class pane. You'll immediately see a list of its member functions in the lower pane. Click on a member function, and that function's declaration appears in the main editing pane.
Now for the coolness. Notice that little blue book icon to the left of the NSObject entry in the Class pane? Click on it. Ka-ching! The NSObject documentation appears in the editing pane. Apple's documentation is extensive. For each class, you'll learn where the class fits into the class hierarchy, protocols it conforms to, in what include files it is declared, methods and fields (with lots of "see also" links), and more. At the very least, spend some time reading about the NSObject class, since the vast majority of your classes will inherit from this class.
Here's another example: Go back to the Class pane and click on the triangle to the left of NSObject. This will reveal the classes derived from NSObject. Near the top of that list is NSArray. Click on the triangle to the left of NSArray, revealing NSMutableArray. Click on the book icon for NSMutableArray. The doc for NSMutableArray will appear in the main pane (see Figure 4).
Figure 4. The documentation for NSMutableArray.
Notice that the doc lists the inheritance hierarchy NSArray : NSObject. As you can see, you've got several ways to find your class in the hierarchy. You can use the triangles to drill down through a parent class. You can also use the "Inherits from" links in the doc to get to an ancestor class.
Now take a look at the popup menu at the bottom of the Members pane. It currently reads "Hierarchy, all classes". There are some other choices as well. Selecting "Hierarchy, project classes" will restrict the class list to classes you've declared in your project. "Flat, all classes" gives you a straight alphabetical listing of all classes, irrespective of hierarchy. This is very useful when you know the name of a class, but don't know where it sits in the class tree. "Flat, project classes" does the same thing, but restricts the list to classes used by your project.
Another nice Project Builder feature is that you can add your own customized views to this list. Figure 5 shows the dialog that appears when you click the Options button to the right of the popup menu. Basically, you use the controls in the dialog to customize the class listing, then click the Add... button. When prompted, name your custom listing, and it will appear in the popup menu along with the other listings. Spend a few minutes playing with this dialog, just so you have a sense of what options are available to you.
Figure 5. This dialog appears when you click the Options button in the Classes tab.
Other Paths to the Documentation
As you might expect, there are other ways to get from a symbol to its documentation. In your CrannyTester project, click on the Files tab, then open the Source triangle and click on main.m. Now hold down the option key and double-click on the class name NSAutoreleasePool.
Ta-daa! Project Builder takes you straight to the doc page for NSAutoreleasePool. To get back to your source code, click on the "back" button (the button the cursor is pointing to in Figure 6). Go ahead, click on it. Just like your browser, it takes you back to the previous page, in this case, your source code.
Figure 6. The cursor is pointing to the back button.
Let's try another experiment. This time, hold down the command key and double-click on NSAutoreleasePool. Instead of jumping to the doc, Project Builder jumps to the declaration of NSAutoreleasePool in NSAutoreleasePool.h.
Notice the two popup menus to the right of the back and forward browser buttons. The first popup (Figure 7) lists the recently visited frames, including source code and documentation. The second popup (Figure 8) allows you to jump to individual declarations within the current source file.
Figure 7. The first popup to the right of the browser buttons shows recently visited files.
Figure 8. The second popup lets you jump to the declarations within the current file.
There are a lot more elements worth exploring within Project Builder but, unfortunately, I've run out of room. More cool stuff next month, plus we'll dig into some actual code. See you then.
Dave Mark is a long-time Mac developer and author and has written a number of books on Macintosh development, including Learn C on the Macintosh, Learn C++ on the Macintosh, and The Macintosh Programming Primer series. Be sure to check out Dave's web site at http://www.spiderworks.com.
