Re: Speaking of tracking rects...
Re: Speaking of tracking rects...
- Subject: Re: Speaking of tracking rects...
- From: "Michael Ash" <email@hidden>
- Date: Sun, 10 Sep 2006 08:33:09 -0400
On 9/9/06, Dave Budde <email@hidden> wrote:
I am working on an app that has several (16 actually) tracking
rectangles for control points in a set of bezier curves. When
implementing the tracking mechanism for mouseEntered and mouseExited
I notice that tracking numbers start at 3 (at least for any
addTrackingRects in my code). What are the other 2 tracking rects for?
And is there a way to reset the trackingNumber? It just seems to
keep going up and up as I run the code. I assume it will wrap and
not fault as I overflow the integer size. Someone speak up if this
isn't true.
So I'm using some modulo arithmetic:
mTrackingNumber = ([theEvent trackingNumber] -3) % 16;
to figure out which trackingRect the mouse entered. This seems a
bit odd. But does work.
No, no, no, no, and also no. Did I mention no?
The tracking rect tag that's returned from addTrackingRect:... is not
documented to follow any behavior other than being unique. The system
would be perfectly fine in returning 42, then 1000000, then -1, etc.
By assuming they start at 3 and work up, you're relying on an
implementation detail that could change at any moment.
The correct way to figure out which tracking rect the mouse entered is
to use the userData: argument of this method. Pass it something handy
and identifying-like, then you can get it back out of the NSEvent when
things come in and do something with it. If you absolutely must use
the tracking rect tag itself, use it as the key to an NSDictionary
which maps arbitrary tags to the useful data you need.
Mike
_______________________________________________
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