@TAC109,
Unfortunately Ahk2Exe has to use CMD here so that stderr can be captured. When errorlevel = 2 this indicates that there is a syntax error in the script being compiled. I installed Weatherlights version from the Store and Ahk2Exe works correctly with his version. I saw that his version has hard links for Ahk2Exe.exe, AutoHotkey.exe AutoHotkeyA32.exe & AutoHotkeyU64.exe in the WindowsApps directory so I made an assumption that these hard links were what enabled this process. I hope you can find a way around this problem.
Okay, so the problem was related to how Windows treats file system virtualization for Store apps. Namely my shell wrapper
AutoHotkey.exe was, among other things, trying to preserve virtualized paths when accessing the AHK directory itself, meaning that for example that if an argument
C:\Program Files\WindowsApps\53721Descolada.AutoHotkeyv2StoreEdition_2.0.10.0_x64__16ny5jw0c3c86\VFS\ProgramFilesX64\AutoHotkey\UX was passed to AutoHotkey.exe, it was converted to
C:\Program Files\AutoHotkey\UX instead. My thinking was that this would provide better compatibility for scripts that expect the regular path, and since scripts launched through AutoHotkey.exe have file system virtualization enabled then that path gets devirtualized properly to the actual path. The virtualization tokens get passed along through Run/RunWait/ShellExecute/CreateProcess, so new launched scripts also have proper virtualization. However, it seems that certain applications launched through these functions do NOT get the virtualization tokens such as cmd.exe and explorer.exe. This meant that ScriptParser.ahk command
RunWait,"%comspec%" /c ""%AhkPath%"... was failing because cmd.exe wasn't able to localize AhkPath
C:\Program Files\AutoHotkey, because it's virtualized and doesn't actually exist!
RunWait, "%AhkPath%" on the other hand doesn't have that problem and was able to proceed normally, which is why the change of
if (ErrorLevel = 2) to
if (ErrorLevel) would've worked.
Weatherlights version didn't attempt such path manipulations and thus AhkPath was pointing to the actual non-virtualized location, which meant RunWait comspec was able to work normally.
I will remove the attempts at preserving virtualization in the next version, so your code should work unchanged then. However, keep in mind that if you launch Ahk2Exe through RunWait comspec, then virtualization will be disabled which means that registry read-writes won't work among other things.
Ahk2Exe is not a console app, however this is fine with me.
I meant that if I wanted to create a hardlink Ahk2Exe.exe but *not* create a Start Menu item, then it would be considered a console application by Microsoft and the restrictions would apply.
I have a 'Check for updates' facility in the Ahk2Exe gui that will obviously not be able to succeed in the Store version.
I've thought and researched about this a little bit more and found that there's an option to enable installed location virtualization for Store apps. It appears that this enables virtualized read-writes to the WindowsApps folder which get redirected to the users AppData folder. Then subsequently reads from WindowsApps get dynamically merged with the AppData changes, which means that you could implement updates via this system.
For example, after running
FileDelete("C:\Program Files\WindowsApps\53721Descolada.AutoHotkeyv2StoreEdition_2.0.10.0_x64__16ny5jw0c3c86\VFS\ProgramFilesX64\AutoHotkey\Compiler\Ahk2Exe.exe"), this redirects Windows to delete a hardlink from the AppData folder
C:\Users\USER\AppData\Local\Packages\53721Descolada.AutoHotkeyv2StoreEdition_16ny5jw0c3c86\LocalCache\Local\Microsoft\WritablePackageRoot\VFS\ProgramFilesX64\AutoHotkey\Compiler and subsequently Ahk2Exe is no longer runnable from AutoHotkey Dash. File replacements will work as well, so you could update Ahk2Exe this way. I don't yet know whether this would work in Windows 10S as well which only allows executables to be run from inside the WindowsApps folder, but I'm sceptical about it and wouldn't recommend implementing auto-updates.
Currently of course this doesn't work because I haven't updated the package yet... When I do then your autoupdater still doesn't work, because the Store version doesn't include AutoHotkeyUX.exe (maybe it should though?). And even when I include it, then I still get an unspecified error which is most likely related to the RunWait comspec calls in Update.ahk which try to do unvirtualized read-writes which of course fail
This method has some quirks.
FileAppend("mytext", "C:\Program Files\AutoHotkey\testfile.txt") doesn't work (throws an error).
FileRead("C:\Program Files\AutoHotkey\UX\launcher.ahk") DOES work, most likely because it's located in the VFS directory.
FileAppend("mytext", SubStr(A_AhkPath, 1, -StrLen("v2\AutoHotkey64.exe")) "\testfile.txt") creates the virtualized file in the AppData folder, and reading it with
FileRead(SubStr(A_AhkPath, 1, -StrLen("v2\AutoHotkey64.exe")) "\testfile.txt") works, but
FileRead("C:\Program Files\AutoHotkey\testfile.txt") doesn't work. I wish Windows had made this stuff simpler...