Hotstrings sometimes not working Topic is solved

[kunkel321]

I've seen this for the last month or two but haven't reported it because I can't reliably reproduce it. I have Win 10 and Office 2016. Usually I see this either in Word, or when trying to rename a file in my Explorer replacement (xyplorer). Just now it happened in a text editor too. What I have noticed is that stopping and re-starting my script doesn't help. Closing and re-opening my Word doc *sometimes* helps. There is never a problem with any script that is activated via hoykey combo.
I don't know if it matters, but my script is huge. It's an evolved version of the (awesome) AutoCorrect.ahk script. 1000s of hot strings. When it happens, it just acts like my script isn't even running. I type the hotstring and nothing happened. Also of possible relevance: If I switch to a different application/window, then the hotsting replacement *does* work. But if I go back to my Word doc or whatever, it doesn't work.

As I type this, it occurs to me that I haven't checked the version number of the Autohotkey.exe that I'm using. I'll post if there's any luck there. Can anyone else think of things to try?
Edit:
--------------------------
version number.ahk
---------------------------
my ahk version: 1.1.23.01
---------------------------
OK
---------------------------
Upgrading now...

EDIT2: Okay then... At risk of getting my own thread off-topic:
The zip for 1.1.27.7 didn't contain "AutoHotkey.exe." It only has
AutoHotkeyA32.exe
AutoHotkeyU64.exe
AutoHotkeyU32.exe
Can one of these be used as a "runtime" for my .ahk file. (For example by renaming it "autocorrect.exe" and putting it in the directory of "autocorrect.ahk?")
Strike that!
Sorry! I see that AutoHotkeyA32 will work.

It's SchTE4A that wasn't working (because it was looking to the file called "AutoHotkey.exe."

I'll try v 1.1.27.7 for a while and see if my original concern with the hotstrings is still present.

[gregster]

Okay then... At risk of getting my own thread off-topic:
The zip for 1.1.27.7 didn't contain "AutoHotkey.exe." It only has
AutoHotkeyA32.exe
AutoHotkeyU64.exe
AutoHotkeyU32.exe

That is normal for the zip-version, which is the "portable" version; there, you can rename any of the three versions to "autohotkey.exe", depending on which bitness and encoding you want. A32: Ansi 32 bit, U32: Unicode 32 bit, U64: Unicode 64 bit.

Instead, you could use the installer version which will lead you through the install/update process... https://autohotkey.com/download/ahk-install.exe or click the link called "Download Autohotkey Installer" with the blue background above the zip version here: https://autohotkey.com/download/ ... or, use the download link at the top of the forum.

Can one of these be used as a "runtime" for my .ahk file. (For example by renaming it "autocorrect.exe" and putting it in the directory of "autocorrect.ahk?")

Yes, that should work as long as the chosen AHK version is compatible with your script and your windows version (ex: 64 bit AHK cannot run on 32 bit windows), but in this case you will have to start the exe which will then automatically look for an ahk-script of the same name in this directory. Compare section "Script Filename" in https://autohotkey.com/docs/Scripts.htm#cmd

Concerning your actual problem I have no idea at the moment. Perhaps you can reproduce the problem with a smaller part of your script and post it here for inspection?!?

[kunkel321]

Thanks for the reply gregster! I must've used the installer version last time and forgotten. Good Idea with using a smaller script to test with. If the problem persists, I'll try this.

[kunkel321]

I made an additional separate script consists of only one line of code:

Code: Select all

#NoEnv
#SingleInstance force
;#################################

::;test::This is a test of the AutoHotkey Broadcasting System.  This is only a test.

When my main script became non-responsive, I tried the above and it was also non responsive.

Again, reloading the script does not make it responsive. Reopening the document I'm working on sometimes does.

I'm not sure if it's relevant, but many of my hotstings (as with the above sample) start with a semicolon. All of my hotstings become unresponsive though--whether or not that start with ";"
Also as indicated in the first post, only hotstrings become unresponsive. Scripts activated via Hotkey continue working as normal.

Does anyone have other ideas of how I can remedy this? Or at least isolate it so that I can offer a useful bug report?

[lexikos]

You can try gathering input with the Input command, which uses some of the same code as the hotstring recognizer. If the hotstring recognizer is not receiving the expected text, maybe the Input command will reveal the problem.

You can also try the preview of v1.1.28, in case I have inadvertently fixed the issue while working on the hotstring code.

[kunkel321]

Thanks lexikos!

I have been trying v1.1.28, and unfortunately I still see the problem occasionally. Regarding the Input command, I updated my extra temporary script to be as follows:

Code: Select all

#NoEnv
#SingleInstance force
;#################################

::;fold::My New Folder

^!i::
Input, OutputVar, L3 
    MsgBox, Output var is %OutputVar%

Hopefully this is the correct usage(?) Unfortunately I've also gotten inconsistent results with this! As indicated above, the hotstring error sometimes occurs in Word, but more often occurs in my file manager. So last week with my file manager, AutoHotkey would ignore my hotstring for inserting today's date ;d0. But if I pressed my hotkey ^!i then typed, the message box would pop up with "Output var is ;d0" which I guess indicates that AutoHotkey can see the input.

This morning I got a different effect though. My hotstrings were not working in MS Word 2016, so I tried the hotkey ^!i and the script did not seem to run--which is to say my keystrokes didn't get "caught" by AutoHotkey, they just got typed into the Word doc I was working on. Oddly, some of my GUI based tools which are hotkey-activated did continue to work. Also odd, is that I opened Notepad to see if my hotstrings would work in there. Upon doing this, the above Input script activated and caught my first three keystrokes--apparently it had been "waiting" for a different application before running (??) I don't know.

Any other ideas for debugging this?

EDIT: I forgot to mention that last week with my file manager, several times I'd try to inline-rename a newly-created folder and the hotstring ::;fold::My New Folder did expand as expected, but trying to insert the date after that ";d0" did not work. This effect was not consistent.

Hopefully my explanations make sense.

EDIT2: Eh... Sorry to report this, but I just tried an older version AutoHotkey_1.1.27.02 and the problem immediately stopped. I'll use this version for a day or two and see if the problem doesn't resurface. If it doen't I'll try to figure out exactly which version is the last working version. It might take a while though, since this is an intermittently occurring problem.
Well strike that... The problem occurred again this morning with the older version 1.1.27.02. I think lexikos might have the answer in his reply though... More below.

[lexikos]

Make sure Word is not running as administrator, such as if it is launched by another program which is running as administrator. By default, Windows prevents applications from hooking keyboard events intended for higher-privileged applications (as part of "UIPI"). If the script was waiting for "Input", it would continue waiting until you activate a window which the script can monitor.

If Word is running as administrator, you can try the workarounds listed in the FAQ.

If hotstrings stop working but some of your hotkeys continue to work, it could be that the keyboard hook is not detecting keyboard events (or the OS is not routing events through our keyboard hook). Use ListHotkeys to check whether the hotkeys use the "k-hook" method or "reg" method.

[kunkel321]

Just a quick reply: Thanks lexikos! I'm not sure how to check if Word is running as administrator, but it's worth noting that the problem was occurring most often in my explorer replacement which does definitely get ran as administrator. I told my scripts to run as administrator as well (per the recommendations in the FAQ) and so far so good! I will try this for a couple of days and report back.

[kunkel321]

Okay, I'm marking this as "answered." I started using to most recent version of AutoHotkey again and have enabled "Run as administrator." The problem has not occurred even once. Unfortunately if a script is made to run as administrator, then it seems that you can't put in in the Startup folder of Windows 10. It is possible to make a Task Scheduler item as described here though: http://www.thewindowsclub.com/autostart ... ws-10-make Ironically, this has caused another problem altogether--but I'll post that as a new thread.

Thanks again, everyone, for the assistance!

[lexikos]

Instead of running as administrator (which is not recommended in the FAQ at all, merely listed as a "common workaround"), you can run the script with UI access. (I'm not entirely certain it will work from the Startup folder, but you can definitely launch it via Run from a normal script in Startup, as I do.)

The workarounds are listed in descending order of preference.

[kunkel321]

Thanks for clarifying this lexikos! I actually did notice the first item in the list of workarounds, but I'm using AutoHotkey as a portable application, so I'm guessing this precludes that ability to run the setup(?)

As a side note: I stopped using the "installed-version" of AutoHotkey because the security on my work computer prevented me from editing any of my config files (which were in the Program Files folder). I guess using an elevated text editor might have fixed that though.

It's all good though. My current setup is working as needed.