Run "i_view64.exe" and other programs moving the mouse cursor?!

[emp00]

Dear Team, I use hotkeys to start several programs with Run. Found this strange effect -> Run starts the program and moves the mouse cursor to the just opened window, which I don't like! I want the mouse cursor to stay where it is when I press the hotkey. I'm on Win11 with AHK 2.0.13. This does not happen e.g. with the classic notepad.exe or mspaint.exe but for example these following 3 programs are affected:

- Win11 Snipping Tool (C:\Users\xxxxxx\AppData\Local\Microsoft\WindowsApps\SnippingTool.exe)
- Password Safe (pwsafe.exe, free password manager tool)
- Irfan View (i_view64.exe, Portable version in my case)

See below a super-simple script example, this is what happens on my PC:
- Pressing F3 starts up Irfan View and moves the mouse cursor to the center of the Irfan View window!
- This only happens when using AHK's Run command: When double-clicking i_view64.exe or a shortcut on the desktop this does not happen, mouse stays in position.
- Same effect with the other programs and I have a few more of those candidates (but surely not all programs show this)...

Can you reproduce this? Could this be an AHK bug or do I make a mistake?
Anybody have a solution to prevent this undesired mouse movement when using AHK's "Run"?

Code: Select all

F1:: Run "C:\Users\xxxxxx\AppData\Local\Microsoft\WindowsApps\SnippingTool.exe"
F2:: Run "E:\Programs\Password_Safe\pwsafe.exe"
F3:: Run "E:\Programs\IrfanView_Portable\i_view64.exe"

[mikeyww]

Hello,

I would fix the syntax error and then post your revised script. The effect of moving the mouse cursor has nothing to do with the script that you posted. There could be other scripts or programs that move the cursor.

[emp00]

I would fix the syntax error and then post your revised script. The effect of moving the mouse cursor has nothing to do with the script that you posted. There could be other scripts or programs that move the cursor.

Syntax error fixed. Please test yourself, of course you need to adjust the paths... I am not aware of any programs on my PC which could cause this, but hints are welcome.

[emp00]

I checked further: Actually, this does not happen when the Desktop is in focus! But it always happens when any window/program is currently in focus. This is the boundary condition - you need to have e.g. notepad.exe running, it's window active/in focus and then you press one of the hotkeys. The mouse moves towards the newly opened window!

Could this be a Win11 functionality, something I can switch off somewhere?
Again: This only happens with the AHK Run command, not when double-clicking the icon starting exactly the same exe file...

[mikeyww]

When you revise a script, please do not edit your post. Create a new reply.

Tested without any problems here.

This may be easy to debug if you close all other programs, scripts, macros, keyboard utilities, mouse utilities, clipboard utilities, and tray-resident programs. Re-test. Use only the script that you posted, with no other code, no additions, and no changes.

[lexikos]

Found this strange effect -> Run starts the program and moves the mouse cursor to the just opened window, which I don't like!

This has nothing to do with Run. Run just starts the program. I'll bet it happens when any new window opens, not just when a program starts, or when AutoHotkey starts a program.

If your system language is English, go into Control Panel (not Settings) and search for mouse. Then under Ease of Access Center, select "Change how your mouse works". You should find a setting "Activate a window by hovering over it with the mouse". Turn this off.

Having this setting enabled causes what you describe, because if it did not move the mouse pointer, whatever mouse was under the mouse pointer would reactivate instead of the newly opened window.

[emp00]

If your system language is English, go into Control Panel (not Settings) and search for mouse. Then under Ease of Access Center, select "Change how your mouse works". You should find a setting "Activate a window by hovering over it with the mouse". Turn this off.

Having this setting enabled causes what you describe, because if it did not move the mouse pointer, whatever mouse was under the mouse pointer would reactivate instead of the newly opened window.

Indeed I have "XMouse Options" enabled (automatically activating windows under the mouse cursor with 1200 ms delay)! Switching this off indeed restores the "Run"-behavior to normal. Thank you for this hint - however, I don't want to miss my XMouse functionality, this is very important for my productivity. If I understand you correctly, this is caused when Run-ning a program while the mouse cursor is standing still? By testing I can confirm that the mouse move effect does not occur when I press the hotkey while slowly moving the mouse!

Here's my workaround idea: See below "RunMoveMouse"-function - however it does not work yet, probably because the commands are running sequentially? How can I move the mouse (just a tiny bit) in parallel while Run is executing, so that the above mouse cursor jump is programmatically prevented? Thanks for looking into this.

Code: Select all

RunMouseMove(Program)
{
	; Workaround function for XMouse functionality
	; This function shall "wiggle/move" the mouse while Run is executing thus preventing a jumping mouse cursor
	MouseMove(+5, +5, 100, "Relative") ; Move mouse some px, 100=slowly
	Run(Program) ; Regular run command
	MouseMove(-5, -5, 100, "Relative") ; Move mouse px back, 100=slowly 
}

[lexikos]

Run doesn't wait for the program to start up. MouseMove may execute before the program finishes initializes and shows its window. A mouse movement is not a gradual process, but a series of instant changes in mouse coordinates, with a delay between each change. In other words, this is as much "in parallel" as you can get.

How the system would determine whether "the mouse is moving" is likely a matter of what length of time it measures the movements over, and perhaps the magnitude of movement. It might only consider movements coming from the mouse driver, and not input injected by a program. The mouse hardware can report movements more finely than simulated input can generate, and can be detected even if it doesn't result in a visible movement of the cursor.