Re: NSCell mouse tracking best practices.

FROM : Corbin Dunn
DATE : Sat Jul 08 00:18:24 2006

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

> On Wed, 5 Jul 2006 20:23:16 -0700, Corbin Dunn <<email_removed>> 
> 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