The mouse is where, again?
The mouse is where, again?
- Subject: The mouse is where, again?
- From: Quincey Morris <email@hidden>
- Date: Sun, 27 Jan 2008 16:54:58 -0800
Probably no one is interested, since there wasn't a lot of response
when I posted about this earlier, but here are some (partial) answers
to the questions I raised:
(A) The weird behavior of mouseEntered: when dragging is Working As
Documented. There's a NSTrackingEnabledDuringMouseDrag option when
creating a tracking area whose name is misleading but whose behavior
is correctly described. When using NSTrackingMouseEnteredAndExited
tracking, mouseExited: events are always sent at the correct time,
regardless of the option. mouseEntered: events are sent at the correct
time *with* the option, and deferred till the mouse button is released
*without* the option.
I bet there's a reason why it's like this, but I just can't figure it
out.
(B) The problem of finding out whether the mouse is inside or outside
the tracking area at the time you turn on tracking is mostly an error
in the documentation. If you specify the NSTrackingAssumeInside
option, what actually happens is you will subsequently get a
mouseExited: event if the mouse is actually outside the tracking area.
(In other words, you will subsequently get told your assumption was
wrong.)
What the documentation actually says about this option really makes no
sense, but to the extent it makes any sense at all it's flat out
wrong. The Leopard release notes indirectly describe the correct
behavior, which -- since it also applies to the old-style tracking
rects -- is a kind of bug fix since Tiger.
However, the current behavior is still kind of brain-damaged, because:
-- Every view not using NSTrackingAssumeInside risks being wrong about
whether mouse is inside any of its tracking areas until one or two
actual inside/outside transitions occur, depending where the mouse
started.
-- Every view using NSTrackingAssumeInside is wrong about whether the
mouse is inside or outside -- if by chance the mouse is initially
outside -- until the initial mouseExited: event arrives.
-- Testing shows that this initial mouseExited: event does not get
sent until the mouse actually moves.
If you're using tracking and you're fine with your application having
an even chance of being wrong until the mouse moves, you're golden. :)
(C) I still see no way to get the mouse location, synchronized with
the event loop, when you have no NSEvent to get it from. In almost all
cases, pace Jayson*, it is incorrect to use the real-time-now mouse
location returned by (say) [NSEvent mouseLocation].
Usually, you can use the mouse location from the last mouse-related
NSEvent you saw, without the location being more than a little bit
stale, but there are 2 cases where this is problematic:
-- When your application starts up, before you've received any events.
This is similar to the problem with tracking, and apparently you have
to live with the chance of being wrong until a mouse NSEvent arrives.
-- When a view not under your control sucks events out of the event
queue so that you don't get to see them. (When the user tabs into a
text field, for example.) By the time you see another mouse event,
your last-remembered mouse location can be very stale.
It's possible you could subclass NSApplication in such a way as to
monitor all events regardless of which view they end up being eaten
by, but this seems ugly, fragile, and perhaps not even feasible.
If anyone knows of a way around this, I'd still be very happy to know
about it.
--
*On Jan 25, 2008, at 17:43, Jayson Adams wrote:
But I also argue that the only thing that *ever* really matters is
where the mouse is, as you say, *now*. ... If I'm dragging out a
selection rect, for example, it's a bug if the corner of the
selection rect is not always under the mouse.
This is intuitive, plausible, but ... wrong. For example, it's clearly
a bug if the corner of the selection rect *is* under the mouse, if the
mouse button has been released but you don't know it yet because the
mouseUp event is still in the event queue. (It only took me 3 days to
figure that out.)
In general, the mouse location is connected with a lot of other state
(including, most importantly, the state of the mouse button and the
state of the keyboard modifier keys) which means you generally have to
stay synchronized with the event queue.
_______________________________________________
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