Subject: [SOLVED] Re: Can NSTrackingArea rects be nested?
On Mar 28, 2009, at 2:31 AM, Quincey Morris wrote:
On Mar 27, 2009, at 15:48, Stuart Malin wrote:
I have a view that contains an NSTextView. I place NSTrackingAreas
on portions of the TextView's text. I attach a userInfo dictionary
to each of the tracking areas with a variety of parameters. The view
containing the TextView happens also to have an NSTrackingArea
around its entire frame. The NSTrackingAreaOptions are set to report
mouse entered/exited for all of these tracking areas.
When the mouse enters the outer (containing) view, *all* of the
tracking areas report the event, even though the mouse has not
entered any of the nested tracking areas. I thought perhaps I needed
to do hit testing of the mouse's hit point to see if it was in the
tracking area's rect. But this doesn't work, because the event's
tracking area as reported by [[event trackingArea] rect] is, in all
cases, the rect of the containing view. However, if I examine the
content of the event's userData, it is associated with the distinct
smaller, contained (nested) tracking areas.
If [[event trackingArea] rect] is the rect of the containing view,
then the actual behavior sounds correct (though not what you want, of
course) -- if all the tracking areas have the same rect, they should
all notify on the same mouse move. So the real question is why do they
all have the same rect? You didn't by any chance specify the
NSTrackingInVisibleRect option for them?
Thanks Quincey -- I sure did have NSTrackingInVisibleRect set for the
nested tracking areas (which, btw, do not have the same initializing
rect). Removing NSTrackingInVisibleRect from the options fixed my
"problem" -- which was more of a problem of me not fully understanding
the description of the NSTrackingInVisibleRect option -- but in going
back to the docs, they certainly do say that the visibleRect is
returned (I just didn't get the implication of this...
For clarity in the archival record: the "problem" I queried regarding
has nothing to do with there being nested tracking areas. In fact, in
trying to root this problem out, I had removed the outer containing
tracking area and still was seeing the "problem."
As for NSTrackingInVisibleRect: I'm a bit mystified by its utility. I
had though that what I was achieving by including this option was that
the tracking area would not be triggered for parts of the rect that
were visually occluded. However, it seems to function in quite a
Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)
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 maillists@xxxxxxxxx