Blog Moved

I moved the blog. Here's the new blog location.

I have also moved all of the blog post from here and all the comments to the new blog location. If you want to comment on a post, go to the new blog location.

Xcode 3 Book in the Works

You may have noticed I have not updated my site or this blog much recently. I've hinted at the reason in the past, but a bunch of people emailed me with questions about it so I figured I should write about it here. I am working on a new edition of Xcode Tools Sensei, specifically written for Xcode 3. Two questions come to mind.

What's Going to be in the New Edition?

There will be a lot of new material in the new edition, and I don't want to drone on and on about the new material. Some of the highlights include the following:

• Xcode 3's new features, including refactoring tools, code folding, and the Research Assistant.
  
• Interface Builder 3.
  
• A new chapter on Instruments.
  
• The version control chapter will use Subversion instead of CVS.
  

When Will the New Edition be Released?

I don't know the exact date, but I hope to have it finished this summer (winter for those of you in the Southern Hemisphere). I do know it will not be released before Apple's Worldwide Developer Conference (WWDC), which runs from June 9 to June 13. Apple is expected to release Xcode 3.1 and the iPhone SDK at WWDC. Because WWDC is less than two months away, it would be a waste of time to rush to release an Xcode 3 book, then put out a big update covering Xcode 3.1 and iPhone development. Doing so would also be a disservice to people buying the print version of the book.

SDL File Loading When Running from Visual C++'s Debugger

I was testing some texture loading code on Visual C++ 2005 and 2008. The code compiled fine, but when I ran it from Visual C++'s debugger, it crashed every time. The code crashed because the program could not find my image file so it could not read the file and load the image. But the code ran file when I ran it from Windows Explorer. Why could my image file be found when I ran my program from Windows Explorer, but not from Visual C++'s debugger?

The reason was that Visual C++'s debugger uses a different working directory. Windows normally sets the working directory to the same directory as the executable file, which is where I had my image file. But Visual C++'s debugger sets the working directory to the directory containing the project file. Where is the project file? When you create a Visual C++ project, Visual C++ creates a folder that has the same name as the project name. Inside this folder is a second folder that has the same name as the project name. The project file resides in the second folder. The second folder is where the image file needed to be to debug my program. Moving my image file to the second folder fixed the crashing problem inside the Visual C++ debugger.

If you're using Visual C++ to write a game and you want to run the game inside the debugger, make sure your game's files are in the same directory as the project file.

XcodeTemplateFactory

Hog Bay Software recently released XcodeTemplateFactory, a utility that converts an Xcode project to a project template. I tried XcodeTemplateFactory, and it is an easy way to create Xcode project templates.

Building XcodeTemplateFactory

When you download XcodeTemplateFactory, you get an Xcode project file called XcodeTemplateFactory. Open the project in Xcode and build it to create the XcodeTemplateFactory app.

Creating a Project Template with XcodeTemplateFactory

To convert a project to a project template, run the XcodeTemplateFactory app that you built. Click the Choose button to open an Open File dialog box. Navigate to the folder containing your project and click the Open button. Enter a description of your project in the Project Description field. Make the description a good one. When you create a new Xcode project and select your template from the template list, your description is going to appear underneath the template list. Click the Generate Template button, and you've created an Xcode project template.

Xcode 3 Template Location Clarification

In a previous post on Xcode 3's new locations for project and file templates, I said project and file templates needed to be in the following locations:

Developer/Library/Xcode/Project Templates

Developer/Library/Xcode/File Templates

Those locations are for Apple's templates. While it is technically possible to place your templates with Apple's (I placed some of my SDL and OpenGL project templates with Apple's project templates and had no problems), the Xcode 3 release notes say you're supposed to place your templates in a different location. Project templates belong in the following location:

Library/Application Support/Developer/Shared/Xcode/Project Templates

File templates belong in the following location:

Library/Application Support/Developer/Shared/Xcode/File Templates

You're going to have manually create all the folders after Application Support in the path.

If you use the paths I just mentioned, your project and file templates will be available for all users on your Mac and be available for use in both Xcode 3 and Xcode 2.5. If you want to restrict your templates to a specific version of Xcode, replace Shared with the Xcode version number. If you want only a single user to be able to use your templates, start the path with Username/Library.

Xcode 3 Addition: Python and Ruby Cocoa Project Templates

Xcode 3 includes project templates for writing Cocoa applications in Python and Ruby. Those of you who were turned off of Cocoa by Objective C's syntax can now give Cocoa development a try.

If you installed the developer examples when you installed Xcode 3, you will find on your hard drive many examples of Cocoa programs written in Python and Ruby. You can find the Python examples at the following location:

Developer/Examples/Python/PyObjC

You can find the Ruby examples at the following location:

Developer/Examples/Ruby/RubyCocoa

Interface Builder 3 Change: No Subclass Creation

Older versions of Interface Builder let you create subclasses for Cocoa applications and generate source code files for the subclasses you created. As an example, you could drag an OpenGL view to a window, subclass the OpenGL view, and have Interface Builder create .h and .m files for the subclass. But Interface Builder 3 no longer lets you create subclasses. How do you create the subclasses?

You create the subclasses the old-fashioned way: with source code. Create your subclasses in Xcode. Interface Builder and Xcode are synchronized so the subclasses you create in Xcode appear in Interface Builder as well.

 

Choose File > New File to create a new file. A window will open containing many file types for you to choose from. For a Cocoa program you would want one of the Cocoa files unless you're writing a Cocoa program in Ruby, in which case you would use one of the Ruby files. Name your file and click the Finish button. You've created a subclass file.

Instantiating Your Class

After creating your class in Xcode, you may need to add an instance of your class to the nib file so you can make connections in Interface Builder. If Interface Builder's library window is not open, open it by choosing Tools > Library. The library window contains Interface Builder's user interface elements.

Select an NSObject from the library window. NSObject is a blue cube. Drag NSObject to the nib file window. An NSObject named Object should now appear in the nib file window. Choose Tools >Identity Inspector to open the identity inspector. Select the NSObject in the nib file window.

The top of identity inspector should have a combo box labeled Class. Choose your class from the list of classes in the combo box. The name of the NSObject instance in the nib file window will change from Object to the name of your class. Any outlets and actions in your class should appear in the identity inspector.

If your classes are not appearing in Interface Builder, choose File > Synchronize With Xcode in Interface Builder.

Xcode 3 Change: Run Log

Older versions of Xcode had a run log window that let you view the output of command-line programs. Where did it go in Xcode 3?

In Xcode 3 the run log's name has changed to Console and has become part of the debugger window. The console is initially invisible, which makes locating it difficult. There are two ways to reveal the console. First, you can choose Run > Console to show the console, and you will see the console at the bottom of the debugger window. Second, you can drag the splitter bar at the bottom of the debugger window to reveal the console.

Update (January 16, 2008)

Xcode's debugger window has a splitter bar for the console only if you're using Xcode's All-In-One layout. If you're using the Default or Condensed layouts, the console is a separate window. Clicking the Console button on the debugger window toolbar opens the console for the Default and Condensed layouts. 

Xcode 3 Change: Universal Binaries

The Release build configuration for Xcode 3 is set to create 32-bit universal binaries for Cocoa and Carbon application projects. All you have to do is create a Cocoa or Carbon application project, and you're set to build a universal binary. You'll have to modify the Architectures build setting if you want to build a 64-bit version of your application.

Xcode 3 Change: Release is the Default Build Configuration

In Xcode 3 Apple changed the default build configuration from Debug to Release. This decision does not make much sense. Unless you're writing a simple program, you're going to want to debug your program when you start writing it. Wanting to debug your program means that you want the Debug build configuration, not the Release configuration.

When you create a project with Xcode 3, the first thing you will want to do is change the active build configuration from Release to Debug.