Re: The mouse is where?
Re: The mouse is where?
- Subject: Re: The mouse is where?
- From: Quincey Morris <email@hidden>
- Date: Tue, 29 Jan 2008 10:32:32 -0800
On Jan 29, 2008, at 09:09, Hamish Allan wrote:
By the way, did you report bugs to Apple about the following two
issues?
Surely it's wrong that one of the
two messages works synchronously, and the other asynchronously, when
dragging?
Surely there should be a more-or-less immediate
message (either mouseEntered: or mouseExited:) to tell me where the
frameworks thinks the mouse is?
I wholeheartedly agree with you on both of them!
Hamish
No, I haven't made any bug reports yet.
The first of these is not a bug, after all. I posted on this somewhere
in the middle of the discussion. The "inconsistent" behavior is what's
documented to happen if you *don't* use the "track during drags"
option of the tracking area. Turning on the option makes the messages
appear at the correct time.
The second of these is the tip of a larger iceberg. It turns out that,
even when you ask for the tracking area to stay in sync with the
visibleRect, changing the view bounds causes the view's
updateTrackingAreas to be called, which causes you to recreate the
tracking area. Unfortunately, creating a new tracking area means that
you're at least back at square one: the event system won't tell you
where it thinks the mouse is. You lose your way whenever the view
scrolls, for example. (using a hand-grabber style tool) Worse, what I
actually saw (using a hand-grabber style tool) was if you drag out of
the view, you often get no more mouseEntered: messages until you
release the mouse button, no matter how often you then cross in or out
of the view.
Having found the one sentence in the documentation that explains what
tracking areas mean by "inside" (it's the one-pixel-shorter-than-the-
rectangle-you-first-thought-of thing), I tried manually computing the
inside/outside status whenever I re-created the tracking rect, but
that didn't make the scrolling problems go away, and at this point I'm
not sure whose fault it is. (And I'm afraid it would take a custom-
built test app to resolve that.)
So I'm at the point of being ready to dump the entered/exited tracking
and just do it manually, since it appears I would have to do that at
least some of the time anyway.
However, unless something else shows up, I plan to keep using
NSTrackingAreas for the 2 things they seem to be able to do reliably:
-- generating mouseMoved events local to a view
-- restoring the cursor to the correct thing when the mouse goes
outside one of my own views
Now if I could only get NSClipView to stop changing the cursor to an
arrow whenever it scrolls ...
_______________________________________________
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