Here's a dumb one: My intention was to use the source file GetMetaDataForFile.m in the MetaLinear.codeproj project. Instead, I left the project template's reference to GetMetaDataForFile.c (note the .c suffix) unchanged. The project would try compiling the .c file provided by Apple's importer-project template, and produce a warning that the getter function was not filled. 
 
The sample code disk image that accompanies this site corrects the error. 

Posted by: Fritz Anderson

As I mentioned earlier, Xcode's gcc no longer supports embedded functions (functions defined inside other functions). The earlier note corrected the problem in the printed code in chapter 23. 
 
The sample code on the CD that accompanies Step into Xcode contains another instance of this error. The function in question begins at line 31 in PointStat.m beginning with Chapter_12/2 and all later versions. 
 
Replace that function with a C macro: 
 
#define DoesntImplement(aSelector) ((newDelegate != nil) && \ 
![newDelegate respondsToSelector: aSelector]) 
 
 
The sample-code disk image that accompanies this site reflects the change. 

Posted by: Fritz Anderson

Section 5.2 ends with the sentence, "Now the process of building Linear will include a build, if necessary, of Linrg and will copy Linrg to Linear's Resources directory inside its bundle." This is incorrect. Making Linear dependent on Linrg will cause Linrg to be built in the process of building Linear, but it will not tell Xcode to copy the Linrg tool into Linear's application bundle. 
 
A more-accurate end to section 5.2 would be 

 

Now the process of building Linear will include a build, if necessary, of Linrg.

 

One last step: We don't want simply to build Linrg; we want the Linrg tool to be part of the Linear application's resources. To do this, find Linrg.xcodeproj in the Groups & Files list, and click on the disclosure triangle next to it. This will reveal the Linrg tool product. Drag this icon down to the Targets group, and hold Linrg over the group's icon. The group will open to reveal the target Linear. Drag Linrg over the Linear target, and keep holding it there. A list now opens of the tasks, or build phases, performed in building Linear. One of these phases is "Copy Bundle Resources," which is the phase that moves non-executable files into the application package.

 

Once again, hold Linrg over the Copy Bundle Resources phase; the phase will open up. Drag Linrg so it is just below the Copy Build Resources list item, then release it. Now Linrg is not just a file to be built in Linear's build process, but is marked for copying into the Linear application itself.

 

Posted by: Fritz Anderson

The about-the-author page gave fritza-six@manoverboard.org as my email address, but it seems I never activated it. I've done so now, and I apologize to anyone who tried to reach me at that address before. 

Posted by: Fritz Anderson

I thought I had rid my examples of embedded functions, but one slipped by. As of Xcode 2.2, gcc prohibits the use of embedded functions — functions declared inside another function or method. Section 23.2, by my oversight, includes at page 380 a function, IsQuoted, embedded in the testQuotation method. 
 
Embedded functions are now prohibited because gcc implemented them by pushing the code onto the stack, and executing them there. Many security exploits work by executing code injected into the stack, and it is a prudent security measure to make the stack non-executable, even at the expense of embedded functions. 
 
In this case, you can just move the IsQuoted function outside the testQuotation method, and the file will compile cleanly. 
 
Thanks to Sabreur for finding the bug. 

Posted by: Fritz Anderson

I owe a debt to a reader I'll call Sabreur for submitting an extensive list of errata for Step into Xcode.  
 
I haven't reviewed all of them, but thought it important to get the list out now. The page loses most of the rich-text attributes the author supplied, making some of the notes a bit less clear; I regret that, and will try to make that up as soon as convenient. 
 
I'll log big errors separately. 

Posted by: Fritz Anderson

In section 7.4 (pages 78-79), I have you set up an NSArrayController for the DataPoint array in the document's model object. NSArrayController needs to know the name of the class of the objects in its array (in this case, DataPoint).  
 
Section 7.4 does not tell you to set the Object Class Name, in the inspector (command-1), to DataPoint. You have to do this for archiving and dearchiving the array in a document to work properly. The sample code accompanying Chapter 7 (and later) does set the class name. 
 
Thanks to Bruce Truax for diagnosing the problem and identifying the fix. 

Posted by: Fritz Anderson

This was a bit delayed, but a .dmg file with the contents of the CD that accompanies Step into Xcode is now available from the book’s web site. 

Posted by: Fritz Anderson

One of the things I counted as a loss for CodeWarrior veterans switching to Xcode is speed: The gcc compiler, for good if regrettable reasons, is just not as fast as the highly-optimized compiler built into CodeWarrior.  
 
Events have overtaken me. Reports of compilations on the CoreDuo iMac—which no one would expect to be the fastest of the CD Macs to be introduced this year—have Xcode project builds running much faster than on dual-G5 PowerMacs, comparable to 5-machine build farms and—yes—comparable to PPC CodeWarrior speeds. 
 
You’d expect a hypothetical Intel-compiled CodeWarrior to be faster still, but alas, an Intel-compiled CodeWarrior will be hypothetical forever. 
 
This Intel business may turn out all right. 

Posted by: Fritz Anderson

Step into Xcode has a whole chapter on using bindings to create an application so most of the human-interface work is done by Cocoa. What that chapter doesn't have is information on how to debug bindings—a task that can often be tricky. There is an ADC article on this subject, for which we should all be grateful. 

Posted by: Fritz Anderson

Often, one will hear a programmer exclaim over linker errors or runtime dynamic-load errors that appeared only when an Xcode target was changed from Debug to Release configuration (or from Development to Deployment in older projects). The remarks often take the form of "it worked correctly until I switched to Release, so there must be something wrong with the Release configuration." 
 
Well, no; it wasn't working correctly. The flaw was also present in the Debug configuration, and your application was walking dead when you ran it in the Debug configuration.  
 
The culprit — if there is one — is ZeroLink. ZeroLink, you remember, is a feature that the Debug configuration uses to speed the process of getting a project compiled and running. It does this by skipping virtually all of the work of the linker, leaving the linkage of individual objects to when those objects are used while the program is run. If your project never defines the function foo(), and you never call foo() when you run the Debug version, the application will "run fine." The lack of the definition will never be noticed. 
 
There are two solutions. One might be to exercise 100% of your application while in your Debug phase. Then every module will be loaded, and any that can't be loaded will trigger a run-time error. 100% code coverage is a good thing if you want your debugging phase to debug the whole application, but it isn't practical in every run of the application. 
 
The other solution is to turn ZeroLink off once in a while. Without ZeroLink, building a target will put the application through the full process of linking. One of the services a linker performs is to verify that every symbol you use is defined somewhere. If definitions can't be found for some functions or variables, the linker halts the build with an error message that lists the objects it couldn't find. 
 
The summary view of build errors in the project window or Build Results window won't be detailed enough to include the list of symbols that weren't defined. Open the detailed build log (third button at the bottom of the summary in the Build Results window), where you can find the full text of the linker error, including the missing symbols. 

Posted by: Fritz Anderson

The first thing to remember about Step into Xcode is that it's a book about Xcode. Because Xcode is designed around the programmer's workflow, the first half of the book takes you through the typical workflow of designing and implementing a Cocoa application in Objective-C. 
 
Despite the subtitle of the book, Step into Xcode is not a book about Mac OS X development tout court. It is not a book about languages or frameworks: I go into Objective-C deep enough to make the code examples readable. I explain Cocoa enough to make Xcode's and Interface Builder's features for Cocoa meaningful. 

• Are there better books about Cocoa? Certainly: Any book that is about Cocoa is bound to be a better Cocoa book than a book about Xcode.
 

• I don't cover development for Carbon. This is true, but covering frameworks is not what I set out to do -- I don't cover Cocoa (well) either. The narrative in Part 1 was supposed to demonstrate how Xcode is used; A parallel demonstration for Carbon would be pointless and redundant.
 

• I don't cover the use of Interface Builder for Carbon applications. This is a fair criticism. All I can say is that without a Carbon project to use the resulting NIB, it was hard to fit an example of a Carbon NIB into my narrative.
 

• I don't cover C++. Again, my aim was to explain Xcode, not languages. Also, some of Xcode's features — the class modeler most notably — aren't quite ready for C++. On the one hand, I'd have to discuss those weaknesses (and I think I dissed Xcode enough in the Codewarrior chapter); on the other, I'd expect the weaknesses to be the first things fixed in new versions, and I was reluctant to include material that would go stale during the lifetime of the book.
 

• I don't cover Java. As with Carbon, a parallel narrative focused on Java would be mostly redundant (for my purposes). Also, Xcode is frankly a mediocre tool for Java development. Use Eclipse instead.

Posted by: Fritz Anderson