MouseMove does not move to correct location in multi-monitor setup

[easygoer33]

I just started using your OCR lib and its amazing. However, noticed that if the active window is on a different monitor from the VS Code window in which I am running the code, the mouse move defaults to the VS Code screen. The location of the mouse move is accurate but it is on the VS code screen not on the active window screen.

[Descolada]

I don't have a chance to test this at the moment because I don't have a multimonitor setup. Does adding DllCall("SetThreadDpiAwarenessContext", "ptr", -3, "ptr") to the top of your script change anything?

[easygoer33]

No, it didn't work.

[easygoer33]

It's not important for what I am doing, but just wanted to let you know. Thanks.

[Descolada]

Well, thank you for letting me know. I believe the issue is in the coordinate mode you are using for the mouse, which led me to look more deeply into how the library handles coordinates and change some implementations.

If you are using OCR.FromDesktop or OCR.FromRect, then for your mouse movements make sure you are using CoordMode "Mouse", "Screen".
With OCR.FromWindow, after todays update it uses the value of A_CoordModePixel, so make sure the modes for both Pixel and Mouse are the same when using it. Previously the default was "Window".

[easygoer33]

I am new to AHK and your OCR library. I just updated the OCR library and it still didn't work for me. I am using OCR.FromWindow from Example 4 for a lot of my code. I am not even sure what you mean when you say "make sure the modes for both Pixel and Mouse are the same when using it. Previously the default was "Window"." Anyway, like I said I don't need it for what I am doing but thanks for working on it.

[Descolada]

I am referring to the coordinate systems that AHK can use, namely whether coordinates are relative to the window, client area (which is the default), or screen. You can read more about it from here.

For example, if everything is working correctly then the following script should move the mouse to the first word in the active window when F1 is pressed:

#Requires AutoHotkey v2
#include <OCR>

DllCall("SetThreadDpiAwarenessContext", "ptr", -3)

F1::{
    CoordMode "Mouse", "Window"
    CoordMode "Pixel", "Window"
    result := OCR.FromWindow("A", {lang:"en-US"})
    word := result.Words[1]
    MouseMove word.x, word.y
    word.Highlight()
}

[easygoer33]

Thanks! It works now, even without the dll call.

[ktwb]

Further to my other comment,

CoordMode "Mouse", "Window"
CoordMode "Pixel", "Window"

above the code is gold.

I had some code working off an older version of this library and it stopped working yesterday when I updated to the current version. Specifically, a piece of code reading a screen from Excel would work fine if called directly hotkey -> function(), where function() contains some OCR instruction, but when it was wrapped as function8 -> [...] -> function2 -> function1 -> function() it would start doubling the x return coordinate (noting that I have a monitor to the 'left' of the excel window, effectively treating the origin as not the window anymore). While I can't explain why it did this when wrapped up sufficiently, the above resolves it.

[Descolada]

@ktwb I'm guessing that since a hotkey launches a new thread with fresh coordinate system settings, then it might be that in your function8 you were changing the coordinate mode at some point and thus messing up the coordinates. Hard to tell without testable code :)