Aaron Hillegass _Cocoa Programming for Mac OS X_ Chapter 9 Question

Question

In Aaron Hillegass' Cocoa Programming for Mac OS X, Chapter 9, the section called "Begin Editing on Insert", he explains how to do exactly that. The thing that confused me though, was that he did a bunch of other stuff. Here's the full code listing:

- (IBAction)createEmployee:(id)sender
{
NSWindow *w = [tableView window];

// Try to end any editing that is taking place
BOOL editingEnded = [w makeFirstResponder:w];
if (!editingEnded) {
    NSLog(@"Unable to end editing");
    return;
}
NSUndoManager *undo = [self undoManager];

// Has an edit occurred already in this event?
if ([undo groupingLevel]) {
    // Close the last group
    [undo endUndoGrouping];
    // Open a new group
    [undo beginUndoGrouping];
}
// Create the object
Person *p = [employeeController newObject];

// Add it to the content array of 'employeeController'
[employeeController addObject:p];
[p release];
// Re-sort (in case the user has sorted a column)
[employeeController rearrangeObjects];

// Get the sorted array
NSArray *a = [employeeController arrangedObjects];

// Find the object just added
int row = [a indexOfObjectIdenticalTo:p];
NSLog(@"starting edit of %@ in row %d", p, row);

// Begin the edit in the first column
[tableView editColumn:0
                  row:row
            withEvent:nil
               select:YES];
}

I have two questions regarding this:

1) How do you know you're supposed to do all that stuff? Is there a 'checklist' or something in Apple's doc? Experience?

2) Doesn't this defeat the whole purpose of an array controller if you're having to still rewrite all the methods on your own?

EDIT: I'm mainly wondering how he knew to put these lines in: (since everything else is pretty basic and obvious)

NSWindow *w = [tableView window];

// Try to end any editing that is taking place
BOOL editingEnded = [w makeFirstResponder:w];
if (!editingEnded) {
    NSLog(@"Unable to end editing");
    return;
}
NSUndoManager *undo = [self undoManager];

// Has an edit occurred already in this event?
if ([undo groupingLevel]) {
    // Close the last group
    [undo endUndoGrouping];
    // Open a new group
    [undo beginUndoGrouping];
}

Answer 1

1) He's doing the things that implement the features his program requires. Its not so much an Apple thing (like what delegate methods do I have to implement when adhering to such-and-such protocol) but this is his program's flow. There are probably a million ways to solve this problem.

2) Not sure what you mean, but he seems to be using a lot of built in methods - I dont see him really re-inventing the wheel (example: )

Person *p = [employeeController newObject];

// Add it to the content array of 'employeeController'
[employeeController addObject:p]; // <-- built in method
[p release]; // <-- built in method
// Re-sort (in case the user has sorted a column)
[employeeController rearrangeObjects]; // <-- built in method

// Get the sorted array
NSArray *a = [employeeController arrangedObjects]; // <-- built in method

// Find the object just added
int row = [a indexOfObjectIdenticalTo:p]; // <-- built in method

EDIT

Ok, so for the first message to w, [w makeFirstResponder:w]; we can find from here (http://developer.apple...NSWindow/makeFirstResponder) that an instance of NSWindow supports the makeFirstResponder message. My understanding to do this to NSWindow is so that when the user interacts with it, it will be the first responder, in other words, it will receive any actions for the NSWindow. And by it, I mean 'w'.

1) How do you know you're supposed to do all that stuff? Is there a 'checklist' or something in Apple's doc? Experience?

Great question - I think it comes with experience and working with all the different types of classes and UI Controls. heh = ] I don't know ... maybe someone has a better answer. I'd love to learn!

Found a good link: http://www.cocoadev.com/index.pl?FirstResponder

Answer 2

1) How do you know you're supposed to do all that stuff? Is there a 'checklist' or something in Apple's doc? Experience?

You're right, that code wouldn't occur to most people doing an initial implementation. (I guess that's why it's in the book. You get to benefit from Aaron's experience).

That code would have come as the result of one or more bug reports. In other words, you wouldn't come up with that code initially, but you would eventually.

Try it for yourself. Remove that code then see if you can spot the problems in the running application. Solving those problems requires a combination of SDK knowledge and debugging skill. Both grow with experience.

2) Doesn't this defeat the whole purpose of an array controller if you're having to still rewrite all the methods on your own?

One could argue that the ability to modify the tableview's behavior like that is the whole point of the array controller (as an element of your application's design).

Answer 3

I think most likely he implemented it without those lines, there were undo problems, and he debugged and fixed the issues.