FROM : Ben Lachman
DATE : Sat Apr 19 00:11:11 2008
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. 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. 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. 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>
DATE : Sat Apr 19 00:11:11 2008
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. 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. 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. 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>
| Related mails | Author | Date |
|---|---|---|
| John Stiles | Apr 18, 19:55 | |
| Ben Lachman | Apr 19, 00:11 | |
| John Stiles | Apr 19, 00:28 | |
| John Stiles | Apr 19, 00:37 | |
| Corbin Dunn | Apr 21, 19:14 | |
| John Stiles | Apr 21, 19:43 | |
| Corbin Dunn | Apr 22, 17:50 |






Cocoa mail archive

