mark-wiemer-org/ahkpp

Extension forgot AHK location

Closed this issue · 4 comments

I installed AHK and the AHK++ extension a year ago and have not used it for anything other than to run a simple script nearly every day. Yesterday it was running, today it reports

2023-08-18T23:48:07.259Z AutoHotkey execute bin not found: C:/Program Files/AutoHotkey/v2/AutoHotkey64.exe

The extension settings do indeed show:

Ahk++ › File: Compiler Path
Path to the AHK compiler. (This is the same for both v1 and v2.)
C:/Program Files/AutoHotkey/Compiler/Ahk2Exe.exe

The problem is that my AHK is installed single user under AppData\Local\AutoHotKey. I can fix the extension settings of course, but is there a known issue with the extension reverting to the default bin location for no reason? The extension is AHK++ Version 5.0.2, apparently kept up to date by VSCode, but I don't know if 5.0.2 was installed between yesterday and today.

When clicking on the AHK++ settings cogwheel, you see the option to Install Another Version - you could try winding back to 5.0.1 or earlier.

5.0.2 works fine after I put the locations of the AHK v1 files into the v2 settings (leaving them blank didn't work). I just wondered if changing the existing settings was expected behavior for 5.0.2, and if so, if it could be highlighted better. Seems like a gotcha for a patch release, if that's how it happened.

5.0.0, 5.0.1 and 5.02 were all released in quick succession. At some point, I had to install the latest version of AutoHotkey v2, and adjust the v1/v2 executable paths in AHK++ settings - can't remember at what point though, but I don't particularly recall encountering the error that you did.

Yes, when the name of the settings changed from "compile path" to "compiler path", that reset the settings. You can view the old settings in settings.json via the command palette, and then update the keys to match the new keys. This was noted in the 5.0.0 change log. Please let me know if you have any questions!