Re: Tracking rects, tracking areas and events
Re: Tracking rects, tracking areas and events
- Subject: Re: Tracking rects, tracking areas and events
- From: Erik Österlund <email@hidden>
- Date: Tue, 21 Apr 2009 01:05:07 +0200
Apr 21, 2009 kl. 12:07 AM skrev Quincey Morris:
2. If I register a tracking rect, will the mouseMoved: message keep
on spamming, or will only mouseEntered: and mouseExited: be sent?
Tracking rects have no effect on the production of mouseMoved
messages.
So is there any difference at all between using NSPointInRect on the
mouseMoved: event instead of using tracking rects? I mean, the events
would have been sent anyway, if I understood this correctly. Then it
would also be much easier to dynamically determine which object should
be activated and choose whatever rules you want.
If I understood this correctly, all three are activated with the
setAcceptsMouseMovedEvents: message.
No, setAcceptsMouseMovedEvents is something else again.
If you're not using NSTrackingArea, or if the mouse isn't inside a
NSTrackingArea, you'll get "old-style" mouseMoved events if
setAcceptsMouseMovedEvents: YES has been called for the window. Pre-
Leopard, this was the only way to get mouseMoved events.
If the mouse is inside a NSTrackingArea, you'll get "new-style"
mouseMoved events instead. To prevent confusion, you'd almost
certainly never call setAcceptsMouseMovedEvents: YES if you're using
NSTrackingArea.
Are the "new-style" mouseMoved events the same then, except they are
sent only when mouse is over the area, while "old-style" were sent all
the time? I thought the point with having tracking rects/areas would
be to lower the amount of events sent, and send them only when mouse
entered or exited the area.
Which one will be called?
If you asking about NSTrackingArea, all of the relevant areas
respond. You're responsible for choosing which ones should really do
something.
I suppose that is for the mouseMoved: event, so does the same go for
mouseDragged: events? They seem to be both related and unrelated
somehow since they have the same kind of behaviour but do not need to
be activated to be sent...
Is it possible to create tree-like priorities like views and
subviews?
Not with NSTrackingArea. Keep in mind that mouseEntered/mouseExited/
mouseMoved are sent to the tracking area's owner, regardless of the
view/subview structure. (OTOH cursorUpdate is sent to the topmost
view under the mouse pointer, regardless of the tracking area's
owner.)
If this is an OpenGL-view and it has no subviews, but I'd like to have
the subview behaviour, would the best approach be to just manually
handle events as mentioned earlier, use layers with tracking areas
somehow, or perhaps a completely different solution?
-Fisk
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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 email@hidden