On 09/08/2012, at 3:38 AM, Corbin Dunn <corb...@apple.com> 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 (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to