Mouse position vs event timing

[bghagar]

I made a small program to draw on a 2d picture control while the mouse is clicked:

My question is, how is the mouse position determined with respect to an event being queued AND/OR is the event structure fast enough to catch sequential movement events? I'd specifically like to know if the mouse position is stored with the event or if the mouse position is obtained when the event is processed.

This is better demonstrated on the front panel:

When the mouse is moved quickly the sequential events do not capture the space between points.

I suspect this could be due to how windows handles mouse movement, however any clarification on this would be great.

[GerdW]

Hi bghagar,

---

@bghagar wrote:

I'd specifically like to know if the mouse position is stored with the event or if the mouse position is obtained when the event is processed.

---

You can see this in your image:

In the event all you get from the event node is the reference to your control. You read that reference and then you read the mouse position using a property of the control!

[altenbach]

Not sure why you are complicating things so much. You can get the mouse position directly from the event data node and draw the line using the multiline tool. Make sure to disable event locking and set the history to one.

Also note that we cannot really debug pictures. If you want detailed help attach your vi.

[tst · Accepted solution]

There are two issues here.

The first, as Gerd pointed out, is that you're reading the position from a property of the control. By the time you get to handle the event, the mouse cursor could be somewhere else from where it was when the event happened. You can handle this by using the coordinate data from the event itself, but that's in pane coordinates, which you would have to convert to the picture coordinates. Some controls have built in methods for this (like graphs and listboxes), but for a picture you would have to do this yourself, accounting for the position of the control, the border thickness, the origin of the picture, etc.

Before you do all of that, though, there is the second issue. As you suspected, the way the mouse moves are captured is periodic - if you move the mouse quickly, there will be gaps in the information. If you want a continuous line, you will need to draw lines between the points using code.

[Intaris · Accepted solution]

Here's a tip:

USB HID standard (up to and including USB 2.0) only supports a MAXIMUM poll rate of the mouse position of 1kHz. Most mice do NOT use this full rate, with special "gaming" mice tending to use more of this available bandwidth.

Aside from what others have said (the mouse coordinates are actually part of the mouse event data) the reason why points between aren't captured (assuming your code is done properly) is that there ARE no points in between. There will always be a dX and dY for mouse movement. How your program deals with this is of course a property of how you program your code, but also what your mouse is even delivering. You will never get "seamless" mouse coordinates.

AFAIK, this has been changed with newer USB versions up to more than 1kHz bandwidth. But let's face it, most people's mice support USB 1 or 2 at most.

[bghagar]

This is really what I was looking for.

So the coords values are captured with the event while the property node gets the position of the mouse when the event is processed... which is all a side note to the mouse movement being noncontiguous. Thanks!