Re: The mouse is where?

FROM : Quincey Morris
DATE : Tue Jan 29 19:32:32 2008

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 ...