Re: NSTableView rows and delete key
Re: NSTableView rows and delete key
- Subject: Re: NSTableView rows and delete key
- From: Bill Cheeseman <email@hidden>
- Date: Sun, 28 Jul 2002 08:40:45 -0400
on 02-07-28 7:30 AM, Raphakl Delcroix at email@hidden wrote:
>
I finally found a more simple way to do it :
>
>
in MyGeneralController.m (NSObject subclass), I create a category :
>
>
@implementation NSTableView (KeysEvents)
>
>
- (void) keyDown:(NSEvent *)event {
>
if ([[event characters] isEqualToString:@"\177"]) {
>
>
[[self delegate] removeRows:self]; // custom delegate
>
}
>
}
>
>
...
>
>
@end
This has consequences, which might or might not be desirable in your
application. For example:
1. Every table in your application will remove rows in response to the
delete key.
2. No other table in your application will be able to respond to any other
key, unless you rewrite the category method to make all tables respond to
the other key. You could customize another table to recognize special keys
by subclassing NSTableView there, but then why not subclass it here, too?
3. All table superclasses are blocked from responding to any other keys,
because you didn't pass the keyDown event to super in an else block. That's
easily fixed by rewriting your category. If you leave it as it is, you have
to research all superclasses of NSTableView to satisfy yourself that they
don't need to respond to some other key.
4. You can't test the unique state of a particular table or its context to
determine whether removing a row is currently sensible. You could add such
tests to the category method, but then you would be limited to tests that
make sense for all your tables, preventing you from implementing tests
suitable only for one particular table. You could avoid this problem by
subclassing NSTableView for another table, but then why not subclass it
here, too?
5. In general, writing a category method to replace an existing Cocoa method
is risky. You don't know how the built-in Cocoa method was implemented, such
as what interdependencies it may have with other parts of Cocoa. Did the
built-in method set a flag somewhere in the text system? Did the built-in
method consult a flag somewhere in the drawing system? You can't know for
sure. You can consult the documentation and you can test your application as
long as you like, but ultimately you are left to guess whether your category
method might encounter an unexpected problem someday. (Writing a category
method to add a new capability to an existing class is much safer.)
There's nothing wrong with subclassing in appropriate circumstances. The
warnings you often read about subclassing in Objective-C are really just
admonitions to consider whether some other Objective-C technique might be
more suitable in the circumstances. Objective-C provides alternatives, not
found in most other languages, that are sometimes -- but certainly not
always -- more suitable than subclassing. Subclassing has the advantage of
letting you confine custom behavior to specific instances.
Here's my override of keyDown: in a subclass of NSTableView used to hold
records in an antiques inventory:
- (void)keyDown:(NSEvent *)event {
unichar key = [[event charactersIgnoringModifiers] characterAtIndex:0];
unsigned int flags = [event modifierFlags];
if (key == NSDeleteCharacter && flags == 0 && [self numberOfRows] > 0 &&
[self selectedRow] != -1) {
[[[self window] windowController] deleteAntiqueRecordAction:self];
} else {
[super keyDown:event]; // let somebody else handle the event
}
}
The deleteAntiqueRecordAction: method called here is a custom action method
implemented in my window controller subclass. It applies only to a table
holding antique records. For example, it won't let the user delete a row
containing certain kinds of information about an antique. If I used your
category method, I wouldn't have had the freedom to call it in response to
the delete key in the antiques table if my application also had a table
listing antique dealers, so my ability to customize the antiques table would
have been severely limited. (I know this violates MVC principles somewhat,
since the table view is calling a controller method. I think it's acceptable
to do this when you're dealing with highly specialized subclasses.)
Somebody tell me if I'm wrong about any of this.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.