Page 1 of 1
First time running a thread issue
Posted: 03 Jan 2024, 14:09
by CuriousDad
Hi. I have multiple keyboard commands in a single AHK file. Whenever I activate a command (or thread) for the first time after starting the computer, it would fail to execute the correct command. It may get part of the command correct, but then fail the rest.
For instance, I may have a command to open a folder, create a new tab and open another folder. Result: It opens the first folder without problems, opens the tab (sometimes), gets the name of the second folder wrong.
Another example, I have a command to toggle the second display. Result: It opens the menu (Win+P), but will get the choice of options wrong.
After the first failure, the thread will then work correctly. I thought that if I changed the speed of the entry with KeyDelay, it might help, but it didn't. I am puzzled at why this is occurring and even more puzzled at what the solution might be. Anyone with any solutions? Thanks.
Re: First time running a thread issue
Posted: 03 Jan 2024, 18:52
by gregster
Sounds like a potential timing issue (many programs open slower when opened for the first time). You should make sure that a certain window is active (or at least exists) before proceeding in your code. Typically, WinWaitActive or WinWait could be used for this.
If you need more specific feedback, I would recommend to post some actual code in one of the v1 or v2 'Ask for Help' subforums.
Re: First time running a thread issue
Posted: 06 Jan 2024, 16:37
by CuriousDad
Thanks for the reply. In response to the possibilities (I'm not a computer programmer and I'm responding as a user only):
1. (Many programs open slower when opened for the first time): AutoHotkey is programmed to start upon computer start up. It doesn't matter when initiate the hotkey (right after start up or 10 minutes after I started the computer), the first run of a hotkey function will still have a problem and then perform normally thereafter.
2. (Make sure that a certain window is active (or at least exists): Unfortunately, WinWaitActive and WinWait do not help. I don't believe that this is the issue because the hotkey function will still work normally after the hotkey would fail for the first time.
Just to note: The first run issue doesn't happen with all the hotkey function.
If I am running a program with a hotkey function, it will work. The hangup appears to be in multi-step commands and the commands that follow first line.
For instance, with toggling my second screen:
Code: Select all
!p:: ; Toggle 2nd screen
SetKeyDelay, 250
SendEvent, {LWin Down}{p}{LWin Up}
SendEvent, {p}{p}{Enter}{Esc}
SetKeyDelay, 10
return
It will get the second SendEvent wrong initially and then the hotkey will work after the first failed attempt.
Second note: The initial first run failure is present with other hotkey functions even if I have experienced a hotkey function error. In other words, if the toggling second screen fails initially and then works thereafter, another hotkey function may fail in its first run as well before it starts to work.
Third note: Force shutdown will reset everything and the problem begins again.
Re: First time running a thread issue
Posted: 08 Jan 2024, 23:33
by lmstearn
Is this on a W11 system?
The Windows key is a system key, which brings up a pop-up menu on mine, so might be some background processing/system caching going on.
The following with
SetKeyDelay may impact:
Docs wrote:Note: PressDuration also produces a delay after any change to the modifier key state (Ctrl, Alt, Shift, and Win) needed to support the keys being sent.
Make any difference if you physically use the key before running the script?
Does anything like a
Sleep work (v1):
Code: Select all
SendEvent, {LWin Down}{p}{LWin Up}
Sleep 20
...
Some general items that could relate:
- Is the keyboard set up standard, no OEM keyboard drivers for gaming?
- No issues with both AHK V1
and V2 installed? (Also can issue be repro'd in both versions?)
- AHK has an
exclusion in Windows Defender, no other key events being intercepted by other antivirus.
- No Group Policy restrictions on key usage.
Discover more with programs like Process Explorer or DiskMon from
Sysinternals.