On Feb 15, 2012, at 08:12 , Sean McBride wrote: > In the meantime, I'll create a category method that wraps locationInWindow > and delegates to mouseLocation or similar otherwise.
Depending on how correct you want to be, you do have to be a bit cautious with this. +[NSEvent mouseLocation] isn't synchronized to the event stream, and therefore returns the "wrong" location if the event is significantly out of date (e.g. if the mouse is moving very fast, or if the app is lagging in dequeuing events). The mouseLocation result is also unsynchronized with the keyboard modifier flags. If, for example, an option-click on a certain control causes data to be deleted without a confirmation dialog, then using mouseLocation will eventually bite one of your users who *didn't* option-click on the control. :) The only really safe solution is to throw an exception for accesses to locationInWindow for the wrong kind of event. A third solution is to use +[NSEvent addLocalMonitorForEventsMatchingMask:handler:] (or subclass NSApplication and override sendEvent:) and keep the event-queue-synchronized values of the mouse location and the keyboard modifier flags globally. That makes the information available even when you don't have an event to refer to, which is a considerable convenience. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
