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];
}
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).