Re: NSTableView -editColumn:row:withEvent:select: question

FROM : John Stiles
DATE : Sat Apr 19 00:28:37 2008

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_removed>
> 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_removed>)
>>
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>>
>> This email sent to <email_removed>

>