AutoHotkey Community

Hey thanks for the call .

I am still updating this on a regular bases. I usually check around once-twice per month at the moment (Depends a little bit on how regulary there is an update ). Currently the version 1.1.33.0.6 is in testing and as soon as I am done with that it will be published .

Nice to hear that the Store release made it possible for you guys to use AHK ... makes me a little proud :

@Weatherlight Glad to hear!

So test passed . The update is now in certification with Microsoft and the update will be released in 1-2 days .

Great! I think perhaps we could also provide a link with a note on the download page linking directly to https://www.microsoft.com/en-ca/p/autohotkey-store-edition/9nq8q8j78637

Since as mentioned by @Mortie the Whistler (Emergency Physician) mentioned, it is the only way they can access it for their systems at their hospital.

Thoughts? Reservations?
@tank @lexikos

So I set your github on Watchlist... just heard about 1.1.33.07 and update is already ready for the store aswell. I am currently waiting for the testing to start and afterwards I will submit it to Microsoft for certification.

Awesome!

@Weatherlight
A user is having problems running your Store version of Ahk2Exe, which is giving an 'Invalid Memory ReadWrite' error (see issue #80). We have determined that this error happens when the full path of the source file exceeds 63 characters in length. The normal installed version of Ahk2Exe does not have this problem, and compiles source files with a path length greater than 63 characters successfully. I have also compared the store version of Ahk2Exe against the normal version and found that they are identical.

Is there some store setup information missing from the store version of Ahk2Exe? (I see that the AutoHotkey directory has additional store-specific files which are not present in the \Compiler directory.)

Hope you can help with this.

Hi, I hope this is the right thread to ask. Would it be possible to put all the Start menu shortcuts into one folder? Autohotkey from the store as is generates around 5 shortcuts which is a mess -- 3 different EXEs, then ahk2exe and finally "Window Spy".

Hey

Just wanted to give a short notice that version 1.1.33.10 ist currently in certification and will be released today or tomorrow . The issue #80 "'Invalid Memory ReadWrite" has been resolved by you guys:
"Fixed variables being set to NULL in certain rare cases, causing crashes. The only confirmed case being when a string longer than 63 characters is returned from a function and assigned to a variable while AutoHotkey is running as a Windows store app."

So thank you very much.

@bzzrak: Sadly that is not possible for an MSIX/Store application since the installation technology does not support start menu folders .

bzzrak wrote: ↑

15 Aug 2021, 17:14

Hi, I hope this is the right thread to ask. Would it be possible to put all the Start menu shortcuts into one folder? Autohotkey from the store as is generates around 5 shortcuts which is a mess -- 3 different EXEs, then ahk2exe and finally "Window Spy".

Good news. With the january cumulative update of Windows 11 the start menu icons can be placed into a single folder within the start menu. I implemented this now and it should work if you run the latest update of Windows 11 .

Here is a screenshot:

@Weatherlight Very neat!
I haven't tried windows 11, but good to see. Thanks for this.

@Weatherlight Do you have any plans to package AutoHotkey v2 for the store now that it has had its first release versions?

Hey

sorry for the late reply.

I am still thinking about it... I still analyze AHK2 to see how it can be done and what features I can support.

Hello,
I've contacted @Weatherlight to discuss releasing a v2 version for Store Edition, and he has given me permission to create another Store Edition. I would also like permission from the AHK team (@joedf?) to do that. It would be in a similar manner as Weatherlights one, where it is clearly marked as "unofficial". If I were to be successful at releasing my version, Weatherlight has agreed to keep his version in the store for at least a few months and then would decide whether to discontinue updates for it.

My version would package both v1 and v2, and include all the UX files which v2 includes (Dash, launcher settings etc). For now I have plans to only release a x64 version, but I will look into the ARM builds as well whether I could include them in the future.

In addition to the normal constraints of an MSIX/AppX package (no UIAccess, containerized environment etc), I've hit upon a constraint I can't easily work around: namely MSIX doesn't allow for the Explorer right-click "New"->"AutoHotkey Script" context menu item to execute a program/script, it can only copy one hard-coded file from the package directory to be the "New AutoHotkey Script.ahk". This means that ".ahk" can be associated with only one default new script template: v1, v2, or neither. I've considered making v2 the default and associating another extension (eg ".ah" or ".ah1") with the v1 template, but then it wouldn't be compatible with the native AHK installation. It seems logical to make v2 the default altogether, and users can manually replace it with the v1 template if they want. Perhaps somebody has any input on this?

Sure go ahead! The only thing I'd ask, if possible, is to provide access to one of the staff, myself, lexikos, or tank.
If the only option is mutually exclusive, I'd default to v2. Otherwise, I no expert of MS store.

@Descolada
It seems a bit extreme to set up a separate extension for AutoHotkey v1 just to handle the Windows Explorer 'New' option. As the code for a new v2 is just '#Requires AutoHotkey 2.0' could you perhaps add a comment to that line to change the 2.0 to 1.1 for v1.1. Alternatively you could also include the v1 code block-commented out with suitable enabling instructions for v1 users.

Cheers

Yeah, I'd say just do V2 for various reasons.

Announcing AutoHotkey v2 Store Edition (unofficial)
Direct link: ms-windows-store://pdp/?productid=9PLQFDG8HH9D

Features

• Both AutoHotkey v1 and v2 included
• Automatic updates via Store
• Increased security: no virus warnings, semi-containerized environment
• Possible to install and use in almost any Windows 10+ computer (including S-mode)

How to use
Option 1. Run scripts by double-clicking a .ahk file as normal
Option 2. Run scripts from command line with AutoHotkey.exe script.ahk which selects the appropriate version automatically (using ui-launcher.ahk).
Option 3. Run scripts from command line with AutoHotkeyV2.exe v2script.ahk or AutoHotkeyV1.exe v1script.ahk to run with v1 or v2, bypassing the launcher. Symlinks for these executables are located in C:\Users\USER\AppData\Local\Microsoft\WindowsApps (or via AHK code: EnvGet("LOCALAPPDATA") "\Microsoft\WindowsApps\"). The real location for the exes is in the restricted WindowsApps folder, which should not be used directly nor modified.

To use v2 in VSCode using thqby's extension, open extension settings and set the Interpreter Path to AutoHotkey.exe.

Known limitations/problems

• Currently available only for 64-bit Windows. If there is need for 32-bit version then I'll consider releasing it (currently it's used by <1% of users, so I didn't); and if somebody develops an ARM version of v2 then I can also add that to the Store.
• UIAccess mode is not available, but running as admin is possible (with sufficient privileges, of course)
• Depending on user privilege, registry writes might be virtualized. This means that standard users' registry writes may not be visible globally, but only to scripts ran with AHK Store Edition. All virtualized registry writes are deleted after uninstalling the Store Edition.
• New script context menu item sometimes not visible in Windows 11
• When using thqby's VSCode extension then if Interpreter Path isn't AutoHotkey.exe, registry and file system virtualization is disabled (meaning for example that right-clicking AHK tray icon and selecting WindowSpy doesn't open WindowSpy).

All source code for the project is available on GitHub.

Awesome! Glad this is up and "running" (so-to-speak)