AutoHotKey stopped working after plugging new keyboard, even if I restart computer - autohotkey

I upgraded my keyboard. Problem is that now all the scripts stopped working. Even simple scripts from the tutorials don't work.
This happens in all applications, and ever if I plug in my old keyboard and restart the computer, autohotkey just does not work any more even in my previous configuration. I've tried also running in administrator mode.
What I do see however is the following, that the script works only once each time autohotkey is relaunced. For example:
^j::
Send, My First Script
Return
This works the first time ctrl-j is pressed, however afterwards it does not work again until I restart autohotkey.
Any ideas? I have Windows 10 x64, 1.1.23.05. I did not install any new drivers with the new keyboard (it's a standard usb keyboard, though a mechanical type).
Here are some more examples of simple scripts that don't work:
SetCapslockState AlwaysOff
In this case the first time I press the capslock, it's indeed ignored, but all the next times I click it works normally.
a::return
Again, same behaviour: a is ignored the first time, but next time it works normally, until I restart AHK (and again then it works only the first time).
Note that in all cases I'm running AHK only with the single line scripts you see; nothing else.
Below is the Key History and last lines when pressing Ctrl-J (of the first example)
Window: C:\Files\Tools\AutoHotKey\1.ahk - AutoHotkey v1.1.23.05
Keybd hook: yes
Mouse hook: no
Enabled Timers: 0 of 0 ()
Interrupted threads: 0
Paused threads: 0 of 0 (0 layers)
Modifiers (GetKeyState() now) =
Modifiers (Hook's Logical) =
Modifiers (Hook's Physical) =
Prefix key is down: no
NOTE: To disable the key history shown below, add the line "#KeyHistory 0" anywhere in the script. The same method can be used to change the size of the history buffer. For example: #KeyHistory 100 (Default is 40, Max is 500)
The oldest are listed first. VK=Virtual Key, SC=Scan Code, Elapsed=Seconds since the previous event. Types: h=Hook Hotkey, s=Suppressed (blocked), i=Ignored because it was generated by an AHK script, a=Artificial, #=Disabled via #IfWinActive/Exist, U=Unicode character (SendInput).
VK SC Type Up/Dn Elapsed Key Window
-------------------------------------------------------------------------------------------------------------
74 03F d 11.94 F5 C:\Files\Tools\AutoHotKey\1.ahk - AutoHotkey v1.1.23.05
A2 01D d 3.09 LControl *c:\Files\Tools\AutoHotKey\1.ahk - Notepad++
74 03F d 1.99 F5 C:\Files\Tools\AutoHotKey\1.ahk - AutoHotkey v1.1.23.05
Press [F5] to refresh.
Lines
001: Return (15.77)
003: if ( GetKeyState( "Control" , "P" ) )
007: Return (150.50)

Related

Unmatched Combo prefix KEYDOWN/KEYUP detection and recover, how to?

I am facing a subtle problem, on Autohotkey 1.1.36. Please see this Esc1.ahk :
~Esc & 1:: Esc1()
Esc1()
{
static s_count := 0
s_count++
tooltip, % "Esc1 #" s_count
}
The purpose of this script is: When I press combo-key Esc & 1, a tooltip appears indicating that combo-key is triggered.
Now do the following operation:
Press down Esc when Notepad (or any text editor, EmEditor in my own case) on the host machine is the active window.
Mouse click inside a VMware Workstation VM window.
Release Esc.
Mouse click EmEditor, making it host-machine active window again.
Press key 1, one or more times.
Now, surprising thing happens, tooltip Esc1 #2, Esc1 #3 etc appears, and the letter '1' does NOT get typed into the text editor -- although we have already released Esc.
We can easily imagine what has happened: When we deliberately release Esc not from the host machine but from inside the VM, Autohotkey engine running on the host machine does not get Esc's KEYUP event, so in step 5 above, Autohotkey still thinks the Esc key is being pressed down. This weird behavior persists until we press and release Esc again, from a non-VM window.
So my question is: Is it possible to detect this exceptional situation from our own AHK script, and, what AHK statements can be used to recover from this? By saying "exceptional", I mean: when the physical key-state is actually UP, while Autohotkey engine thinks it is DOWN.
When this mismatch symptom happens, GetKeyState("Esc", "P") returns 1, which means "key pressed", but the physical key state is released. No luck yet.

Automatically reload AutoHotkey script when modified

When testing AutoHotkey scripts, I sometimes forget to reload my scripts after making changes. This leads to me accidentally testing old, outdated versions of my scripts.
Instead of manually reloading the script, I would like to have scripts automatically reload if they have been modified.
How can I make AutoHotkey reload the current script any time a .ahk file is modified?
Somewhere near start of the script, in the auto-execute section
#SingleInstance force
FileGetTime ScriptStartModTime, %A_ScriptFullPath%
SetTimer CheckScriptUpdate, 100, 0x7FFFFFFF ; 100 ms, highest priority
Anywhere in the script (usually somewhere at the bottom):
CheckScriptUpdate() {
global ScriptStartModTime
FileGetTime curModTime, %A_ScriptFullPath%
If (curModTime == ScriptStartModTime)
return
SetTimer CheckScriptUpdate, Off
Loop
{
reload
Sleep 300 ; ms
MsgBox 0x2, %A_ScriptName%, Reload failed. ; 0x2 = Abort/Retry/Ignore
IfMsgBox Abort
ExitApp
IfMsgBox Ignore
break
} ; loops reload on "Retry"
}
This is how I've done it:
#If WinActive("AHK.ahk - Notepad") or WinActive("*AHK.ahk - Notepad")
~^s::
Reload
Return
#If
Checks if the current window is the script that I want autoreloaded whenever I hit Ctrl-S.
The ~ means the default action of Ctrl-S (saving the file) is preserved, and then we simply reload it.
I'm still new at AHK but here's what I've come with.
If you're using Notepad++ to edit AHKS this will run any ahk that's open and currently in focus in Notepad++ on saving with Ctrl-S and won't effect any other file types.
This script only has to be in one running ahk to work on all ahks being modified in Notepad++.
This can be used on multiple text editor programs too like win Notepad just get rid of the ++ associated with Notepad++
~^s:: ; Saves and Runs ANY AHK open in Notepad++
Sleep 150
WinGetTitle, Title, A
Needle := "ahk - Notepad++"
IfInString, Title, %Needle%
{
StringReplace, xxx, Title,- Notepad++, , All
run %xxx%
return
}
else
return

Auto Hot Key: Strange behavior on ControlClick after Gui Submit

I have the following script that sends ControlClick + ControlSend to a window in background (while I'm working in another window). It works ok as expected.
SetTitleMatchMode 2
$F1::
sleep 1000
ControlClick, x400 y470, Notepad
ControlSend,, text, Notepad
return
The problem is: when I add a Gui on the script, the ControlClick behavior becomes odd once I close the Gui (with Submit or Destroy): If I'm working in a window A (Chrome for example) the ControlClick don't work in background anymore: it activates the window B (Notepad) like in the WinActivate command instead.
Here's the script with the issue (same as the previous one but with a simple Gui):
SetTitleMatchMode 2
Gui, Add, Text,, box
Gui, Add, Button, default, OK
Gui, Show, W300 H300
return
GuiClose:
ButtonOK:
Gui, Submit
return
$F1::
sleep 1000
ControlClick, x400 y470, Notepad
ControlSend,, text, Notepad
return
I'm on Windows Vista 32 bits, Autohotkey v1.1.25.01
I can't understand why the Gui Submit is changing the ControlClick bahavior. How can I fix this and let the ControlClick run in background just like it was without the Gui Submit/Destroy?
ps: both windows were maximized.
ControlClick is known to not be very reliable in certain cases. Take a look at the Reliability section in the ControlClick documentation, there are some things you can try:
To improve reliability -- especially during times when the user is
physically moving the mouse during the ControlClick -- one or both of
the following may help:
Use SetControlDelay -1 prior to ControlClick. This avoids holding
the mouse button down during the click, which in turn reduces
interference from the user's physical movement of the mouse.
Specify the string NA anywhere in the sixth parameter (Options) as
shown below:
SetControlDelay -1
ControlClick, Toolbar321, WinTitle,,,, NA
NA avoids marking the target window as active and avoids
merging its input processing with that of the script, which may
prevent physical movement of the mouse from interfering (but usually
only when the target window is not active). However, this method might
not work for all types of windows and controls.

How can I make AutoHotkeys's functions stop working as soon as the .exe is closed?

I'm testing AutoHotkeys as a way to block user's usage of Ctrl, Alt and Windows Key while an application is running. To do this, I compiled the code:
LAlt::return
RAlt::return
LControl::return
RControl::return
RWin::Return
LWin::Return
into an .exe using the compiler that comes with AutoHotkeys.
My problem is that normally when I close the .exe file (either by code using TerminateProcess(,) or manually) the keys are not released immediately. The Windows Key, for example, may take something like 10 seconds to be finely "unlocked" and become able to be used again, and for me this is unacceptable.
So I got two questions:
Is there a way to fix this problem? How can I make the keys to be released as soon as the .exe is closed?
Would there be any improvement if I tryed to get the same functionality by code? Or if I create the hooks by myself I would get the same problem I'm having with AutoHotkeys?
Thanks,
Momergil
AutoHotkey has a built-in command ExitApp for terminating your scripts.
This example makes Esc your termination hotkey:
Esc::ExitApp
It seems like the delay you are experiencing might be related to how long it's taking the process to close.
You could try making the hotkeys conditional with the #If command*
(i.e. they are only blocked when Flag = 1).
Then you can have the script quickly change the context just before ExitApp by using OnExit. The OnExit subroutine is called when the script exits by any means (except when it is killed by something like "End Task"). You can call a subroutine with a hotkey by using the GoSub command.
Flag := 1
OnExit, myExit
Esc::GoSub, myExit
#If Flag
LAlt::return
LCtrl::return
x::return
#If
myExit:
Flag := 0
Exitapp
* The #If command requires Autohotkey_L.
The other option that will be more verbose, but work for AHK basic, is the hotkey command.
Another option is to have AutoHotkey run the target application, and upon application exit, AutoHotkey exits as well. Here's an example with Notepad. When the user closes Notepad, the script gracefully exits.
RunWait, Notepad.exe
ExitApp ; Run after Notepad.exe closes
LAlt::return
RAlt::return
LControl::return
RControl::return
RWin::Return
LWin::Return
I would use winactive to disable these keys. In this example the modyfier keys are disabled for "Evernote". As soon as you switch to another program the keys are restored and when you switch back to Evernote the modifier keys are disabled again.
SetTitleMatchMode, 2 ; Find the string Evernote anywhere in the windows title
#ifWinActive Evernote
LAlt::return
RAlt::return
LControl::return
RControl::return
RWin::Return
LWin::Return
#ifWinActive

Autohotkey: Commands with Alt Key Working Properly only if not Restricted to a Specific Application

I'm trying to add custom keyboard commands to an application using Autohotkey.
In many of these hotkeys I would like to use the alt key in combination with some other key of my choice (any of the standard letters).
All works fine as long as I don't restrict their usage in such a manner that they work in the target application only (via the #IfWinActive directive ). If I do so, the hotkeys themselves still work, however their behavior is very strange.
I found that they get activated either if
a) I hold down the alt key and then press the second key (in my case the 'b' key) twice
or
b) I use this hotkey two times consecutively with a very short delay between the two triggerings
- The above two cases might actually be 1 case. I'm not sure...
I have no problems when doing the same with Shift or CTRL.
The 'b' key is not what's causing the problem - no alt + 'letter' combination works.
I have tried all SendModes, but so far with no effect.
Code sample:
#IfWinActive, MyAppTitle ahk_class MyAppClass
!b::
click 367, 86
return
Alt+letter commands in AutoHotkey such as !b work without issue. It's possible the version at the time of this post contained certain bugs or was out of date from the current version.
For your code, it could be done like so:
!b::
WinGetTitle, Title, A
if (RegExMatch(Title, "MyAppTitle"))
{
MouseClick, left, 367, 86
}
return