On Feb 23, 2012, at 12:09 PM, Markus Spoettl wrote:
> 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 rem
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 wit
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 ha
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 f
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 hav
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 s
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 the
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
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 pr
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
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 m
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 mo
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 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 mo
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 n
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. x:1
16 matches
Mail list logo
