New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
moveMouse() is broken on Windows 10 #77
Comments
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. |
\node_modules\robotjs\test>node mouse.js
...
... 1..6 |
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. |
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. |
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. |
I compiled robotjs from github master sources using node-gyp. |
I also will try this later on other Windows. |
Interesting: moveMouse(1,1) moves mouse precisely on very left top corner (0,0) |
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) |
SetCursorPos(point.x, point.y); instead of mouse_event in mouse.c works very nice. |
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. |
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. |
I found solution: #78 |
@maxdeepfield I think SendInput should be used in windows. It supports multiple input devices and is recommended by MS. |
@Deltatiger agree, but SendInput also must use 65536.0f instead of 65536 or 0xFFFF |
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 |
I was afraid of that, since the current code works for some users. |
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? |
As mentioned in discussion above - SendInput should be used, but this does not help in some cases, SetCursorPos working best for me. |
@maxdeepfield I tried tweaking stuff a bit. Try this out.
I still am using the mouse_event but this gives me close to accurate readings. |
@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. |
Has there been any update to this?
This will make your mouse drift to the top left corner when running it in a loop. |
@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. |
Should we maybe use SetCursorPos for now? I would like to get #105 finished and this is blocking it. |
Actually I'm going to go ahead and merge the appveyor branch. This is broken so the tests should fail. |
Thanks to AutoHotkey, I got it! Looks like they went through the same thing we did: Man I LOVE open source. Anyway, this needs more testing but I'm going to merge it soon. |
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. |
@maxdeepfield could you confirm if the code in the master branch resolves this for you? In my tests moveMouse was accurate. |
@octalmage Works fine for me now. |
Awesome thanks @DomiStyle! I'll release a new version later today. |
v0.3.2 published to npm which fixes this issue. |
Thanks for fixing this @octalmage! 👍 |
Of course! That's why I'm here! |
This code must return { x: 10, y: 10 }
It returns { x: 9, y: 9 }
Not always pos-1, for example if moveMouse(100,100) then getMousePos gives back 98,98
Windows 10 Build 10240 x64
NodeJS 0.12.7 x64
RobotJS 0.2.3 installed via npm
The text was updated successfully, but these errors were encountered: