Personal tools
You are here: Home / Library / Programming / Cocoa

Cocoa Programming

Motiv vs. Cocoa (Small)

Cocoa is the object-oriented programming framework built into the Mac OS X. These notes relate to programming applications using Objective-C, Java, and April and December 2002 versions of Project Builder and Interface Builder. A CD containing these developer tools is bundled with all Macs, and they can be also downloaded after registering with Apple Developer Connection. Getting started with Cocoa means getting used to some heavy OOP terminology: Model-View-Controller pattern, delegation, dynamic responder chain. But once there, there is no looking back.


Cocoa port of ModView (X11) Motif/GL 3D model editor.

Viewer for PaperPort files. In larval state...

Test 9516
Test pattern generator for IBM LCD monitors. Completed.

Truss deformation analysis for instruction. In progress...

HTML Vocabulary
Cocoa port of Classic HTML Vocabulary 2.0. Functional; probably cannot distribute due to the original copyright.




Mailing lists and forums:


Frameworks, objects, tools:

Project Builder extensions:

Mailing list tidbits:


Can't create new document

A brand new document-based app might say that after being renamed (from the default MyDocument). One reference to the old name is tricky to change. Go to Targets pane, select Application Settings subpane and click the Expert button. In the property list, expand CFBundleDocumentTypes and edit the NSDocumentClass.

Incorrect archive: unexpected byte

This might happen during app initialization, while creating a new window object. No solution as of yet. This happens if one changes the default class of an object within a Nib file, say from NSView embedded within a NSScrollView to a NSImageView, using the Inspector window. A possible solution might have something to do with setting the object properties to match the nonstandard type in the awakeFromNib method. Fixed in 10.1?

Illegal expression, found unknown

Code pasted into Project Builder from e.g. browser sometimes includes non-breaking spaces, which are not visible, and yet incomprehensible to the compiler. Search for them (option-space) and replace with regular spaces.

Drawing bitmaps

From macosx-dev list (Java example):

NSBitmapImageRep bitmap = new NSBitmapImageRep(width, height, 8, 4,
    true, false, NSGraphics.CalibratedRGBColorSpace, 0, 0);

Or use NSImage's -addRepresentation: with the imageRep, then use an NSImageView to display the image.

Debate: allocWithZone or alloc

A lot of Cocoa code one sees contains elaborate memory optimizations, using e.g. allocWithZone: rather than just plain alloc. The latest word from Apple apparently is that allocWithZone: can play against system services, and should be avoided. Source: Cheeseman2002.

Debate: NULL or Nil or nil

Objective-C has three kind of pointers, and a different null pointer should be used with each. NULL is the standard (void *)0 C pointer, Nil is the Objective-C null class pointer (seldom used), and nil is the (id)0 Objective-C null instance pointer. The @selector construct produces old-fashioned C pointers (to a function), and so should be replaced by NULL when appropriate. Also, nil can be sent messages, while NULL cannot.


Custom sheets (dialogs that remain attached to a document window) are a source of endless confusion, in part because of official Apple sample code that includes things that others consider wrong. Here is an example of a custom sheet set-up that seems to work. A controller method that brings down a sheet concludes with this:

        [NSApp beginSheet:myPanel
                modalForWindow:[self window] modalDelegate:self
                contextInfo:(void *)[[NSNumber numberWithFloat:payload] retain]];

This sheet is laid out as a panel in the same NIB file as the document window (a separate NIB file is another possibility). This panel is accessible to the window controller (NIB owner) via an outlet named myPanel. The contextInfo can be used to pass data to the delegate method when the sheet ends, but the catch is that this data has to be persistent across function calls: either a pointer to a global or malloc'ed C variable, or a retained Objective-C instance.

The "do" and "don't" buttons in the sheet are wired in the Interface Builder to this controller method:

- (IBAction)closeMyPanel:(id)sender
        [myPanel orderOut:self];
        [NSApp endSheet:myPanel returnCode:([sender tag] == 1) ? NSOKButton : NSCancelButton];

The first line makes the sheet disappear, and the second takes it out of the event loop, invoking automatically the didEndSelector method specified when the sheet was started.

Finally, the didEndSelector delegate method is defined, also in the controller, thusly:

- (void)myPanelDidEnd:(NSWindow *)sheet returnCode:(int)returnCode contextInfo:(void *)contextInfo
        float payload;

if (returnCode == NSCancelButton) return;

payload = [(NSNumber *)contextInfo floatValue]; [(NSNumber *)contextInfo release]; ...

Notice that the return code depends on which sheet button was pressed, so their tags must be appropriately assigned in the Interface Builder. Also note the necessary retain/release on the additional data passed in contextInfo to the delegate method.

« December 2017 »
Upcoming Events
ECCM ECFD 2018 Jun 11, 2018 - Jun 15, 2018 — Glasgow, Scotland
Upcoming events…