• 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: NSCell mouse tracking best practices.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSCell mouse tracking best practices.


  • Subject: Re: NSCell mouse tracking best practices.
  • From: Corbin Dunn <email@hidden>
  • Date: Fri, 7 Jul 2006 15:18:24 -0700


On Jul 6, 2006, at 7:42 PM, Matt Neuburg wrote:

On Wed, 5 Jul 2006 20:23:16 -0700, Corbin Dunn <email@hidden> said:

My app (NotLight) uses an NSImageCell subclass. What I do is:

(1) I implement trackMouse:, as you say.

That's required for NSImageCell because it isn't meant to be tracked. You have to do your own tracking (it, by default, just returns NO).

Great to know (though it's hard to see why I wouldn't want tracking in an
image cell). However, the docs say something very different:


<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
sses/NSCell_Class/Reference/Reference.html#//apple_ref/occ/instm/ NSCell/trac
kMouse:inRect:ofView:untilMouseUp:>


"This method is generally not overridden because the default implementation
invokes other NSCell methods that can be overridden to handle specific
events in a dragging session."

Yes, well, the NSCell doc says "generally", and not "should not". Unfortunately, NSImageCell does override it, and has for quite some time. Personally, I think it is okay to override this method, and sometimes it is required (for instance, if you need to know the cell frame in the mouse up).


Another reason you may override this: say you have one cell, that contains one or more sub-cells. If the event location is within one of the sub-cell's bounds, you can simply delegate tracking to the subcell. This requires overriding this method.


Nothing tells me that NSImageCell "isn't meant to be tracked", so naturally
I assumed that it inherited its behavior from NSCell. As a result I spent a
lot of time trying everything I could think of so as *not* to have to
override this method.

Please file a documentation bug regarding this; be sure to mention that the implementation of NSImageCell overrides the above method, causing the other methods to not be called. The doc team can easily verify this by looking at the sources or asking one of the appropriate engineers. IMHO, things like these need to be carefully documented, and should be mentioned in the headers.



1. Return YES if you handled mouse up in  your trackMouse: method.
2. Return YES from +prefersTrackingUntilMouseUp, which defaults to NO
for NSCell.

I don't grasp how that helps me.

Okay; #1 is required if you handle a mouse up, otherwise, the view (NSTableView and NSMatrix) will continue tracking until a mouseup happens. Basically, the logic, in some simplified pesudocode style is:


NSTableView:
trackMouse: a cell; stop, if it returned YES (meaning it processed mouseUp). If it didn't return YES, keep tracking until a mouseUp happens.


#2: prefersTrackingUntilMouseUp is the value that is passed to trackMouse:. In addition, If prefersTrackingUntilMouseUp is NO, NSTableView when the event wasn't a mouseDown (ie: drag selection from one cell to another).


Changing the value returned from
+prefersTrackingUntilMouseUp changes the value passed into the last argument
of trackMouse:..., but it does not cause my cell to get an event when the
mouse ultimately goes up, which is what I need.

It does this, and slightly some more (see above comment).

Basically, if our trackMouse: event handles the mouseUp event, then you shouldn't have to add any code in NSTableView to do anything special. For NSBrowser and NSMatrix, the rules are different, and depend on the NSMatrixMode set for the matrix. Let me know what you have set, and I may be able to provide some insight (radio/list/ highlight/track each do different tracking things). Plus, it all really depends on how you want it to work, so if you have an existing app to compare it to that will be helpful too.


PS: a plug for WWDC -- I'm giving an "Advanced Controls and Cells"
talk (called "Beyond Buttons") at WWDC this year. I'm covering the ins
and outs of this.

That sounds terrific, and I plan to attend. But it would be cool, too, if
the docs were simply factual and instructive on matrices and cells. m.

I fully agree! Please do log bugs on things that you think are confusing or aren't explained well. Things should be easy to do, and when they aren't something is wrong.


-corbin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: NSCell mouse tracking best practices. (From: Matt Neuburg <email@hidden>)

  • Prev by Date: Re: Hardware Clock
  • Next by Date: Re: Hardware Clock
  • Previous by thread: Re: NSCell mouse tracking best practices.
  • Next by thread: Re: NSCell mouse tracking best practices.
  • Index(es):
    • Date
    • Thread