Re: NSTableView return key and editing
Re: NSTableView return key and editing
- Subject: Re: NSTableView return key and editing
- From: Pete Yandell <email@hidden>
- Date: Fri, 23 May 2003 18:37:40 +1000
You need to subclass NSTableView and override the textDidEndEditing:
method as follows:
- (void)textDidEndEditing:(NSNotification*)notification
{
// This is a hack to make the return key end editing and leave the
selection
// on the current row rather than begin editing the next row. It
works by
// substituting a dodgy key code in place of the return key.
if ([[[notification userInfo] objectForKey:@"NSTextMovement"]
intValue] == NSReturnTextMovement) {
NSMutableDictionary *newUserInfo =
[NSMutableDictionary dictionaryWithDictionary:[notification
userInfo]];
[newUserInfo setObject:[NSNumber
numberWithInt:NSIllegalTextMovement] forKey:@"NSTextMovement"];
NSNotification *newNotification = [NSNotification
notificationWithName:[notification name]
object:[notification object]
userInfo:newUserInfo
];
[super textDidEndEditing:newNotification];
[[self window] makeFirstResponder:self];
}
else
[super textDidEndEditing:notification];
}
I'm pretty sure I originally stole this from one of the Omni
frameworks, so credit goes to them.
On Friday, May 23, 2003, at 11:07 AM, Christopher Corbell wrote:
>
How does one cleverly defeat the continuation of editing items
>
that NSTableView implements with the return key?
>
>
With an editable, single-column table, if you edit an item and
>
hit return, NSTableView then automatically causes the item below
>
it to become open for editing. I do not want this to happen, but
>
trying to defeat it with from the delegate shouldEditTableColumn:
>
doesn't work - if I say no, I get another editColumn: invocation;
>
if I say no twice, I get a third! It won't give up.
>
>
I've put in a one-shot timer that aborts editing after a short time
>
but this
>
seems like an inelegant solution.
>
>
(UI note: my table is sorted alphabetically like the Finder, so
>
when the user changes the name of an item it can trigger a
>
re-sort of the list. This is one major reason why the return-key,
>
spreadsheet-like editing behavior isn't wanted.)
>
>
Thanks for any help,
>
Christopher
>
_______________________________________________
>
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.
>
>
Pete Yandell
http://pete.yandell.com/
_______________________________________________
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.