Re: NSTableView not setting -clickedRow, -clickedColumn as it should
Re: NSTableView not setting -clickedRow, -clickedColumn as it should
- Subject: Re: NSTableView not setting -clickedRow, -clickedColumn as it should
- From: Graham Cox <email@hidden>
- Date: Thu, 09 Aug 2012 08:58:48 +1000
On 09/08/2012, at 3:38 AM, Corbin Dunn <email@hidden> wrote:
> No it hasn't changed, but the clicked row is set *after* you return a menu. That way your menu validation code can use it. I think the DragNDropOutlineView demo shows how to do this.
OKaaay....
I can figure it from the cell rect as suggested, so it's not a problem, but I also agree that this seems a very odd behaviour, so good to know it can/will be changed.
What I'm trying to do is to basically get the table view's delegate (or perhaps it should be data source...?) to return a menu for a given row in response to -menuForEvent: on the view. If it returns nil, the table view's menu will be used. But the current design means it really has to go around the houses: the view punts it to the cell, the cell has to grab the view's delegate and punts it back to the delegate. Though the cell has a -menu property, because of the way that table views use cells (same cell for each row in a given column) this isn't much use, because typically the menu needs to be tuned for the item the row corresponds to. If the table's delegate protocol included a method for returning a menu for a given row, that would be nice, and if implemented by the delegate, the cell could be bypassed.
-----
I found another issue while exploring this, which I'll mention just to warn other developers.
NSCell apparently uses NSCopyObject() to make a copy of itself, and NSTableView copies cells at times, e.g. for hit testing. If you have a custom cell subclass that supports copying, DO NOT use [super copyWithZone:] followed by your custom copy stuff. Since super uses NSCopyObject, any pointer ivars that your custom cell has added has get copied verbatim, (unretained) and then if you set a property on the copy that releases the old pointer, it is now overreleased. Shortly afterwards this will cause an EXC_BAD_ACCESS crash. I thought the modern advice was to avoid NSCopyObject() like the plague for this reason, though I notice that Cocoa still does use it itself (particularly NSImage and NSImageRep).
--Graham
_______________________________________________
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