• 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: NSView mouseDown truncated coordinates
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSView mouseDown truncated coordinates


  • Subject: Re: NSView mouseDown truncated coordinates
  • From: Quincey Morris <email@hidden>
  • Date: Thu, 23 Feb 2012 11:07:51 -0800

On Feb 23, 2012, at 10:27 , Markus Spoettl wrote:

> I'm using a mouse and the cursor doesn't move between -mouseMove: and -mouseDown: (on screen). If the device would be capable of reporting sub-pixel movements (which may not be reported by moving the cursor), I guess it would have done so by sending an additional -mouseMove: event. If it didn't, I have to assume it didn't notice any movement and therefore didn't report any.
>
> That (maybe flawed) theory asside, I just know that it didn't move because as an operator I made sure of it (when hunting a bug like this, one first assumes operator mistakes, I did too).

I think the theory *is* flawed. Just because the pointer stays in the same place doesn't mean that a sub-pixel-resolution device didn't detect a change. Perhaps even the air temperature can change the reading. :)

Actually, the theory I was working on was that doing anything physical to the mouse, moving it or pressing on it or pressing on the surface underneath it, could cause the reading to change for a short period of time after the mouse-down was detected.

> Up until now (< Lion), it was guaranteed (well, maybe not that, it just happened to work that way) that the -moveMoved: location corresponded to the subsequent -mouseDown: location. That meant that any hover-effects visualized during -mouseMoved: would have been rendered on objects that react in some way when the mouse goes down on them.

Aha! You fell into my carefully prepared trap!

Are you talking about mouseMoved or mouseDragged?

If you're talking about mouseDragged, then the variation comes under the heading of "debouncing" the initial part of the movement, and you should probably be doing that anyway.

If you're talking about mouseMoved, then you already have a change of context involved. When the mouse is up, "hover-effects" should (presumably) refer to which object will be grabbed if you mouse down. When the mouse is down, they should (presumably) refer to which 2nd object the dragged object is being dragged to. If you're relying on mouseMoved to keep the *dragged* object highlighted in some way, I think you're Doing It Wrong™.


_______________________________________________

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: NSView mouseDown truncated coordinates
      • From: Markus Spoettl <email@hidden>
References: 
 >Re: NSView mouseDown truncated coordinates (From: Markus Spoettl <email@hidden>)
 >Re: NSView mouseDown truncated coordinates (From: Quincey Morris <email@hidden>)
 >Re: NSView mouseDown truncated coordinates (From: Markus Spoettl <email@hidden>)

  • Prev by Date: Re: text field question
  • Next by Date: Re: Determining user's clock preference on iOS
  • Previous by thread: Re: NSView mouseDown truncated coordinates
  • Next by thread: Re: NSView mouseDown truncated coordinates
  • Index(es):
    • Date
    • Thread