NSTableView -editColumn:row:withEvent:select: question
NSTableView -editColumn:row:withEvent:select: question
- Subject: NSTableView -editColumn:row:withEvent:select: question
- From: John Stiles <email@hidden>
- Date: Fri, 18 Apr 2008 10:55:38 -0700
The docs for -editColumn:row:withEvent:select: ominously claim:
The row at rowIndex must be selected prior to calling
editColumn:row:withEvent:select:, or an exception will be raised.
I'm implementing a subclass of NSTableView which behaves a little more
like an Excel spreadsheet—it maintains a phony selection by overloading
-mouseDown/Dragged/Up: and coloring cell backgrounds as appropriate. It
works great. But it means that the table view, internally, never
actually considers a row to be "selected." My subclass handles that
entirely on its own and leaves the table view out of it.
Now I'm getting around to implementing the part where the user can edit
table cells in place, and since I wanted to follow the rules in the
docs, I started by implementing it like this:
[myTableView selectRow:inRow byExtendingSelection:NO];
[myTableView editColumn:inCol row:inRow withEvent:myEvent select:NO];
It worked fine but, of course, the entire row turned blue, ruining the
spreadsheet illusion.
So just to see what would happen, I tried removing the call to
-selectRow:: and, lo and behold! No exception. It worked great. Looks
just like how I want it to look.
Am I getting lucky here? Are the docs just wrong? I don't want to do
something overtly dangerous, but in practice it does exactly what I
want... are there any gotchas?
I'm on Leopard FWIW, and don't need to target older OSes.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden