• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: The mouse is where, again?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The mouse is where, again?


  • Subject: Re: The mouse is where, again?
  • From: Jayson Adams <email@hidden>
  • Date: Sun, 27 Jan 2008 17:41:33 -0800


On Jan 27, 2008, at 4:54 PM, Quincey Morris wrote:

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

The answer to whether or not the mouse is within the tracking rect bounds is NSPointInRect([NSEvent mouseLocation], trackingRect) (you have to convert the mouse location to your view coordinate system, of course).


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

This sentence doesn't make sense to me, but again, using the real- time mouse location is always most correct, because it's where the mouse actually is!


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

Sorry, it's correct. And why would the mouse up event ever just be sitting in the event queue?


We're talking about a standard event loop here where you do something on each drag event. The only difference is using the current mouse location instead of the mouse location as claimed by the drag event:

while ([nextEvent type] != NSLeftMouseUp) {
mouseLocation = [[self window] mouseLocationOutsideOfEventStream];


	   if (NSEqualPoints(mouselocation, lastMouseLocation)) {
             continue;
         }

         lastMouseLocation = mouseLocation;

         /* mouse drag processing */

nextEvent = [[self window] nextEventMatchingMask:NSLeftMouseDraggedMask | NSLeftMouseUpMask];
}


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.

Staying synchronized to the event queue has nothing to do with using the most up-to-date information about the mouse's location.


Best,


__jayson

Circus Ponies NoteBook - Organization for a Creative Mind
www.circusponies.com



_______________________________________________

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


  • Follow-Ups:
    • Re: The mouse is where, again?
      • From: Quincey Morris <email@hidden>
References: 
 >The mouse is where? (From: email@hidden)
 >Re: The mouse is where? (From: Jayson Adams <email@hidden>)
 >Re: The mouse is where? (From: email@hidden)
 >Re: The mouse is where? (From: Jayson Adams <email@hidden>)
 >The mouse is where, again? (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: stringByReplacingOccurrencesOfString in Tiger
  • Next by Date: Sending IBActions to selectedObject of an NSArrayController
  • Previous by thread: The mouse is where, again?
  • Next by thread: Re: The mouse is where, again?
  • Index(es):
    • Date
    • Thread