-
Notifications
You must be signed in to change notification settings - Fork 24
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
moveMouseToPosition() doesn't move mouse to correct position #10
Comments
Digging a bit, I think I might see the issue:
But even then, I would expect |
Ah, ok this is interesting: So I have 1 4k monitor and 2 1920x1200 monitors, so half of the total pixels in the I notice if I do
This is just the same scaling done in I am still confused though, is this the intended behavior? Having to renormalize all this myself seems annoying. And it's not clear how I'm supposed to handle this in a generic way so that I can reliably target pixels on any monitor, or a monitor with a specific window or application open. |
It does seem to actually move to the correct coordinates when I only have one monitor. That's a relief at least; is this a limitation of the library then that it doesn't support accurate mouse movement with more than one monitor? |
Hi, This behavior seems to be related exclusively to the Interception driver. Your best bet is to search for documentation in the original C library, or you may want to get in touch with the author, but it looks like you already discovered you need to normalize the values to a from your monitor coordinates all the time. |
Ah, I see! I will follow that thread then, thanks! Also thanks for quick reply :) |
After some digging, I found an additional pitfall I thought I'd note for anyone else who hits this issue. After following up with oblitum, he confirmed the normalization is required. But I discovered that normalization is different depending on the arrangement of the monitors. For example, with my setup like
When moving along the Anyways, if your monitors are stacked vertically, this problem flips and you have to do this for the X axis I believe. And if you have one monitor to the left and one above, I bet you have to do both. I tested it a little bit, forget the details. Basically, if you really want to be sure you are moving the mouse to the right spot on a multi-monitor system, you're probably best off writing some code to calibrate and make sure the mouse is going where you expect it. |
Ah I see now. I remembered this was related to the driver, but I didn't remember that I wrote a function to hide this from users. In that case, the function needs to be fixed to support multiple monitors. |
Yeah, I will try to put out a PR. I will be a bit unavailable over the next week, but I'll reach ping out again when I have the PR together |
I found, if change in AutoHotpy from: |
I've got a setup with 3 monitors where my primary monitor is in the middle. I have a loop that's something like:
This shows that on my primary monitor, the mouse coordinates range from:
x:0 -> x:1919
y:0 -> y:1199
Which makes sense, considering the monitor is 1920 x 1200.
If I go to my left-most monitor, the
x
values returned are negative, from-1
to-3840
which makes sense because it is a 4k monitor. They
values only go to 864 though, which is odd.. Not sure if that is due to UI scaling?Anyways, given all this, if I do:
I would expect it to land in the same spot where my loop above would show 500,500.
What actually happens is the mouse ends up on my leftmost monitor at
-3040, 360
.Do you have any idea why this is happening?
This is on a Windows 10 environment.
The text was updated successfully, but these errors were encountered: