Re: NSCell mouse tracking best practices.
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