• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSTableView not setting -clickedRow, -clickedColumn as it should
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • Follow-Ups:
    • Re: NSTableView not setting -clickedRow, -clickedColumn as it should
      • From: Markus Spoettl <email@hidden>
References: 
 >NSTableView not setting -clickedRow, -clickedColumn as it should (From: Graham Cox <email@hidden>)
 >Re: NSTableView not setting -clickedRow, -clickedColumn as it should (From: Corbin Dunn <email@hidden>)

  • Prev by Date: Re: +underPageBackgroundColor
  • Next by Date: Another NSOutlineView issue
  • Previous by thread: Re: NSTableView not setting -clickedRow, -clickedColumn as it should
  • Next by thread: Re: NSTableView not setting -clickedRow, -clickedColumn as it should
  • Index(es):
    • Date
    • Thread