• Choose a category
• All
• Classic-Fiction

Always use the Debug build configuration during development. The Release configuration has had its debugging symbols stripped. The debugger will act a bit strangely when it is dealing with a program with no debugging symbols.

Here are some common problems and common fixes:

Nothing happens. You probably forgot to make a connection in Interface Builder. Thus, the pointer is nil. Remember that messages sent to nil do nothing.

Made connection, still nothing happens. You probably misspelled the name of a method. Objective-C is case sensitive, so setFoo: is completely different from setfoo:. Try putting in a log statement or putting a breakpoint on the method to see whether it is getting called.

Application crashes. If you send a message to an object that has been deallocated, it will crash your program. (This is difficult to do if you are using ARC or the garbage collector.) Hunting these crashers can be difficult; after all, the problem object has already been deallocated. One way to hunt them down is to ask the frameworks to turn your objects into “zombies” instead of deallocating them. When you send a message to a zombie, it throws a descriptive exception that says something like, “You tried to send the message -count to a freed instance of the class Fido.” This will stop the debugger on that line.

To turn on zombies, open the Product menu and select Edit Scheme.... Select the Run (application name).app action and switch to the Diagnostics tab. Check Enable Zombie Objects.

No objects are being freed, it still crashes. Check the type of your arguments. For example, this is a great way to crash your app:

int x = 5;

NSLog(@"x is %@", x);

See the problem? x is an int, but %@ specifies an object.

Interface Builder won’t let me make a connection. A .h file is messed up. A missing semicolon? A variable declared to be NSTabView instead of NSTableView? Look carefully.

Chapter 6. Helper Objects

Once upon a time, there was a man with no name. Knight Industries decided that if this man were given guns and wheels and booster rockets, he would be the perfect crime-fighting tool. First, they thought, “Let’s subclass him and override everything we need to add the guns and wheels and booster rockets.” The problem was that to subclass Michael Knight, you would need to know an awful lot about his guts so that you could wire them to guns and booster rockets. So instead, they created a helper object, the Knight Industries 2000, or “KITT the super car.”

Note how this is different from the RoboCop approach. RoboCop was a man subclassed and extended. The whole RoboCop project involved dozens of surgeons who extended the man’s brain into a fighting machine. This is the approach taken with many object-oriented frameworks.

While approaching the perimeter of an arms dealer’s compound, Michael Knight would speak to KITT over his watch-radio. “KITT,” he would say, “I need to get to the other side of that wall.” KITT would then blast a big hole in the wall with a small rocket. After destroying the wall, Kitt would return control to Michael, who would stroll through the rubble.

Many objects in the Cocoa framework are extended in much the same way. That is, an existing object needs to be extended for your purpose. Instead of subclassing the table view, you simply supply it with a helper object. For example, when a table view is about to display itself, it will turn to the helper object to ask such things as, “How many rows of data am I displaying?” and “What should be displayed in the first column, second row?”

Thus, to extend an existing Cocoa class, you will frequently create a helper object. This chapter focuses on creating helper objects and connecting them to the standard Cocoa objects.

Delegates

In the SpeakLine application, the use of your interface would be more obvious if the Stop button remained disabled unless the speech synthesizer were speaking and if the Speak button