moveMouse() is broken on Windows 10 about robotjs

[octalmage]

Hi Max!

Could you try putting a sleep between the two? I believe the mouse event is just taking longer on your computer. The tests confirm that getting and setting like that should work as expected.

[maxdeepfield]

\node_modules\robotjs\test>node mouse.js
TAP version 13
Get the initial mouse position.
ok 1 successfully retrieved mouse position.
ok 2 mousepos.x is a valid value.
ok 3 mousepos.y is a valid value.
Move the mouse.
ok 4 successfully moved the mouse.
not ok 5 mousepos.x is correct.

---

operator: ok
expected: true
actual:   false

...
not ok 6 mousepos.y is correct.

---

operator: ok
expected: true
actual:   false

...

1..6
tests 6
pass 4
fail 2

[octalmage]

Yeah those tests failing mean it's the mouse delay. :/

You could use RobotJS from GitHub which includes a setMouseDelay function. The default delay is currently 10ms and I knew this was going to be an issue.

[maxdeepfield]

robot.moveMouse(10, 10);
setTimeout(function(){
    console.log(robot.getMousePos());
},1000);
// { x: 9, y: 9 }

It seems like mouse always try to reach 0,0 coordinates.

[octalmage]

Hmm that's super odd! Thanks for trying that.

@Deltatiger could you try the above code when you get a chance? It works in my VM, I wonder if it's a Windows 10 issue.

[maxdeepfield]

I compiled robotjs from github master sources using node-gyp.
Sad, but it works same. :(

[maxdeepfield]

I also will try this later on other Windows.

[maxdeepfield]

Interesting: moveMouse(1,1) moves mouse precisely on very left top corner (0,0)
I think this is not getMousePos problem, but moveMouse issue...

[maxdeepfield]

var pos = robot.getMousePos();
robot.moveMouse(pos.x, pos.y);

This should not do anything, but it moves cursor a bit to left and top according to current position (depends of current position distance from 0,0, very far - very large step)

[maxdeepfield]

SetCursorPos(point.x, point.y); instead of mouse_event in mouse.c works very nice.

[octalmage]

Thanks that's good to know! I believe mouse _event is being deprecated anyway. I'll use this as an opportunity to test different mouse setting functions ( I believe there's 4 ways on Windows). If I remember correctly, SendInput works really well.

[maxdeepfield]

I tested SendInput and it worked like mouse_event - weird 65535 divisions seems to be not so precise. Maybe this depends on some mouse or screen configuration.

[maxdeepfield]

I found solution: #78
This will work for SendInput too.

[Deltatiger]

@maxdeepfield I think SendInput should be used in windows. It supports multiple input devices and is recommended by MS.
@octalmage I will test things out again in Windows 7 and 10. Just to check if things work out. Also will set up a branch on my repo to convert stuff to SendInput(Mouse and Keyboard). If that works out then it should be better.

[maxdeepfield]

@Deltatiger agree, but SendInput also must use 65536.0f instead of 65536 or 0xFFFF

[maxdeepfield]

Strange, but this 65536.0f correction doesnot work very fine using over remote desktop. Its is now going closer, but not so precise as SetCursorPos

[octalmage]

I was afraid of that, since the current code works for some users.

[dkrutsko]

The mouse code has some issues, first of all why is mouse_event being used instead of SendInput? According to MSDN mouse_event has been deprecated for quite some time. As for mouse movement why not use SetCursorPos here?

[maxdeepfield]

As mentioned in discussion above - SendInput should be used, but this does not help in some cases, SetCursorPos working best for me.

[Deltatiger]

@maxdeepfield I tried tweaking stuff a bit. Try this out.

point.x = ceil(point.x * 65536.0 / GetSystemMetrics(SM_CXSCREEN));
point.y = ceil(point.y * 65536.0 / GetSystemMetrics(SM_CYSCREEN));

I still am using the mouse_event but this gives me close to accurate readings.

[Deltatiger]

@octalmage @maxdeepfield So the issue was mouse_event was dealing with the screen by normalizing it between values 0 to 65536. Very inaccurate if you ask me. The rounding issue fixes it a bit. But to completely fix it we would have to migrate to SendInput. That deals with pixels directly.

[DomiStyle]

Has there been any update to this?
I had issues with my mouse drifting when using moveMouse on Windows 10.

var mouse = robot.getMousePos();
robot.moveMouse(mouse.x, mouse.y);

This will make your mouse drift to the top left corner when running it in a loop.

[Deltatiger]

@DomiStyle This is an issue with Windows API that is being used currently. The problem has already been identified. Will send a PR soon so that it can be fixed.

[octalmage]

Should we maybe use SetCursorPos for now? I would like to get #105 finished and this is blocking it.

[octalmage]

Actually I'm going to go ahead and merge the appveyor branch. This is broken so the tests should fail.

[octalmage]

Thanks to AutoHotkey, I got it! Looks like they went through the same thing we did:

https://github.com/Lexikos/AutoHotkey_L/blob/a0bc036d4f09825b3478f14ffcaca11c782782e0/source/keyboard_mouse.cpp#L2447

Man I LOVE open source.

Anyway, this needs more testing but I'm going to merge it soon.

[octalmage]

We can switch to SendInput later, it should be easy now that we have the conversion down. I'll open a new issue for this.

[octalmage]

@maxdeepfield could you confirm if the code in the master branch resolves this for you? In my tests moveMouse was accurate.

[DomiStyle]

@octalmage Works fine for me now.

[octalmage]

Awesome thanks @DomiStyle! I'll release a new version later today.

[octalmage]

v0.3.2 published to npm which fixes this issue.

[ChrisAntaki]

Thanks for fixing this @octalmage! 👍

[octalmage]

Of course! That's why I'm here!