On Feb 23, 2012, at 12:09 , Markus Spoettl wrote: > This is what I do: > > 1) On -mouseMoved: locate object under the cursor and highlight it so the > user knows which one of them will be operated on when the mouse goes down. > > 2) On -mouseDown: locate object under the cursor and prepare it for dragging > (by remembering it). > > 3) On -mouseDragged: drag the object selected in (2) > > Pretty standard stuff. Of course this relies on steps (1) and (2) locating > the same object. > > Apparently one can't assume (1) and (2) produce the same coordinates, > although I think that's a bug or at least it's unclear what the relationship > of coordinates between mouseMoved: and mouseDown: is.
Ah, it's clear now. But I still think your theory is flawed. You can't assume that the physical act of pressing the mouse button doesn't change the reading (that is, doesn't possibly move the mouse slightly). I don't think that the rounding in mouseDown has anything to do with it. All we know is that currently, the mouse can move during the act of pressing down without producing a new mouseMoved, whereas previously it didn't behave like that -- or, not often enough to notice. Incidentally, I have some event-related code that's evolved for years over a series of different apps, and I noticed recently that in its last evolution a couple of years ago, I apparently arranged for all of the common events (mouseEntered, mouseExited, mouseMoved, mouseDown, mouseUp, mouseDragged, keyDown and keyUp) to always call cursorUpdate before doing whatever else they do. That allowed me to consolidate the hover-highlight-detection in one place (cursorUpdate), and gave consistency to the highlighting in cases exactly like the one you're describing. I mention this approach because I worried that (a) calling cursorUpdate additional times might be a performance problem [it isn't, not in any case I've noticed] and (b) there might be a problem passing the event object from a different event to the cursorUpdate method [there isn't, that I can tell]. Maybe you can give this approach a try. It means you don't have to keep any additional state, which was a concern you mentioned earlier. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
