Re: NSTableView -editColumn:row:withEvent:select: question
Re: NSTableView -editColumn:row:withEvent:select: question
- Subject: Re: NSTableView -editColumn:row:withEvent:select: question
- From: John Stiles <email@hidden>
- Date: Fri, 18 Apr 2008 15:28:37 -0700
Ben Lachman wrote:
Well, you should be able to just override the drawing code, since
thats really your problem. Going directly against the docs, while it
may work fine now, is playing with fire in my opinion.
Yeah… that's why I posted :) I was hoping to get a "oh yeah, that only
applies if [...], file a radar on the docs" or something.
To get the drawing you want, you can just implement
tableView:willDisplayCell:forTableColumn:row: in the delegate and
manually switch selection highlighting on or off depending on whether
the table column passed to you is the selected table column.
That's a thought. I'll look into that. I already use the delegate method
for my "selected"-cell coloring.
You'll probably have to have a couple more cases if you're really
trying to get close to the standard spreadsheet functionality that
lets you select the full row/column by clicking on the header.
Fortunately I don't need to worry about that in this case. Not a problem.
But this should get you started, hopefully.
->Ben
--
Ben Lachman
Acacia Tree Software
http://acaciatreesoftware.com
email@hidden
740.590.0009
On Apr 18, 2008, at 1:55 PM, John Stiles wrote:
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
_______________________________________________
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