On Feb 23, 2012, at 14:15 , Markus Spoettl wrote:
Mouse movement highlighting must happen when the mouse moves. At that time,
only the mouse move coordinates are known. They correspond with what happens
on the screen, so highlighting works as expected.
Now a mouse-down comes along with
Hello,
On 28.11.11 15:40, Richard Somers wrote:
However, the mouseDown and mouseUp events always produce truncated
coordinates.
e.g. x:140.00 y:128.00
This causes inaccuracy with hit testing between mouseMoved and
mouseDown.
Using floor, ceil, or round on the returned value
On 28.11.11 15:40, Richard Somers wrote:
I'm using a NSTrackingArea in a view to receive mouseMoved events.
The cursor location in the mouseMoved and mouseDragged events have
non-integer coordinates (as expected). e.g. x:140.601562
y:128.082031
However, the mouseDown and mouseUp events always
On Feb 23, 2012, at 04:04 , Markus Spoettl wrote:
As an illustration for the list, I have logged coordinates of a mouse move
and a subsequent mouse down event that followed the move event:
mouseMovedToPoint:NSPoint: {217.15625, 343.3984375}
mouseDownAtPoint:NSPoint: {217, 344}
It can
On 23.02.12 18:53, Quincey Morris wrote:
Anyone know how to work out mouseDown coordinates one can expect to
get when looking at mouseMove coordinates?
I'll ask the stupid question:
How do you know (or, why do you assume) that these two sets of
coordinates represent the same point? Even if
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
On 23.02.12 20:07, Quincey Morris wrote:
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
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
On 23.02.12 21:55, Quincey Morris wrote:
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
On Nov 25, 2011, at 6:17 PM, Steven Spencer wrote:
I'm using a NSTrackingArea in a view to receive mouseMoved events.
The cursor location in the mouseMoved and mouseDragged events have
non-integer coordinates (as expected).
e.g. x:140.601562 y:128.082031
However, the mouseDown and mouseUp
BTW, I was informed off-list that an app can also receive higher-precision
coordinates in mouse events if the user is working with a tablet (Wacom etc.)
This could obviously be useful in paint apps for antialiasing brushstrokes.
—Jens
___
Cocoa-dev
Many thanks for your replies, Jens and Ken.
I use the mouseMoved event to set the mouse cursor according to whether a
NSBezierPath instance contains the mouse point [pathInstance containsPoint:],
to indicate whether the path can be moved. There is no scale transformation on
the view. On the
On Nov 25, 2011, at 5:17 PM, Steven Spencer wrote:
I'm using a NSTrackingArea in a view to receive mouseMoved events.
The cursor location in the mouseMoved and mouseDragged events have
non-integer coordinates (as expected).
e.g. x:140.601562 y:128.082031
Weird; I don’t think I’ve seen
On Nov 25, 2011, at 7:17 PM, Steven Spencer wrote:
I'm using a NSTrackingArea in a view to receive mouseMoved events.
The cursor location in the mouseMoved and mouseDragged events have
non-integer coordinates (as expected).
e.g. x:140.601562 y:128.082031
However, the mouseDown and mouseUp
Hi,
I'm using a NSTrackingArea in a view to receive mouseMoved events.
The cursor location in the mouseMoved and mouseDragged events have non-integer
coordinates (as expected).
e.g. x:140.601562 y:128.082031
However, the mouseDown and mouseUp events always produce truncated coordinates.
e.g.
15 matches
Mail list logo
