AutoHotkey v2.0-beta.1 - AHK-EXE-Swapper

[burque505]

AHK-EXE-Swapper installs ahkdll-v2beta-release-master.zip just fine for me.
Trying to install AutoHotkey_2.0-beta.1.zip fails. It creates a subdirectory "C:\Program Files\AutoHotkey\AHK-EXE-Swapper\Versions\Working" with the archive contents in it.
For all other zips it creates a directory named for the version.
There is no listing for AutoHotkey_2.0-beta.1, nor for "Working".

I tried removing everything but the executables and re-zipping the archive, that didn't work either.

All help appreciated.
Regards,
burque505

[burque505]

If i make these changes at line 426 I can get the script to create the 2.0 beta.1 folder in the "Versions" folder

Code: Select all

		if (file = "a32" || file = "u32" || file = "u64" || file = "32" || file = "64"){

but thereafter it won't switch. The next time I run the .exe I get a mismatch warning. Some slight progress, but no banana.

[TheArkive]

To start troubleshooting this, you can change the exe specified in the ProgID (in the registry) that is associated with the .ahk extension. This can be done manually.

The proper key is:

Code: Select all

HKEY_CURRENT_USER\SOFTWARE\Classes\[ProgID]\Shell\Open\Command
or
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\[ProgID]\Shell\Open\Command

If you are using a normal AHK installer or my portable installer, the ProgID name is AutoHotkeyScript. Not sure if the ProgID is different when using AHK Swapper.

Anyways, you can not only change this manually, but you can also have reg files made up for quick and easy switching too.

Let me know if any of this helps, or if you at least get different problems. I know solidifying a process for this is sometimes tricky.

Depending on how this is setup, it could be also in the .ahk extension also.

Code: Select all

HKEY_CURRENT_USER\SOFTWARE\Classes\.ahk\Shell\Open\Command
or
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ahk\Shell\Open\Command

The default .ahk extension can have it's default reg value for the .ahk key set to the ProgID:

image.png (7.15 KiB) Viewed 3932 times

You can of course make these changes manually as well. When you install/uninstall with normal AHK installer, these reg keys should appear/disappear. I'm interested to know if that is indeed what is happening on your system when you install/uninstall/switch. Or if something might be interfering.

If you want to try @SKAN's setup, here's some links to get you started:

AhkSetExtension() : Extension updater for AutoHotkey interpreters.

Re: installing AHKv2 and setting up a .ahk2 extension

Re: AhkSetIcons() : Icon updater for AutoHotkey interpreters

[TheArkive]

Given some of the problems you are describing, I would expect that sometimes (maybe every time?) when you switch ahk versions, you might get a Win 10 prompt asking to you confirm which exe you want to use to run ahk files, but this is normally only done when you have more than one ProgID registered to handle the same file extension.

Do you ever get any such prompt?

[burque505]

Thanks, @TheArkive, hopefully later today I'll get a chance to work on it. The only time I got a prompt like that is when whichever script I was using totally uninstalled AutoHotkey.
AHK-EXE-Swapper doesn't write to the registry, which is a plus for me. It completely swaps out folders in C:\Program Files\AutoHotkey in such a way that there's always an AutoHotkey.exe available to run scripts.
The problem with AHK-EXE-Swapper and v2 beta, as I see it so far, is a matter of properly parsing file names. At present it's not set up to handle the difference in file names that happened with beta.
Swapper uses this code by @SKAN to extract the file version directly from the EXE (I think ):

Spoiler

Code: Select all

FileGetVersionInfo_AW( peFile="", StringFileInfo="", Delimiter="|") {   ; Written by SKAN
 ; www.autohotkey.com/forum/viewtopic.php?p=233188#233188  CD:24-Nov-2008 / LM:27-Oct-2010
 Static CS, HexVal, Sps="                        ", DLL="Version\", StrGet="StrGet"
 If ( CS = "" )
  CS := A_IsUnicode ? "W" : "A", HexVal := "msvcrt\s" (A_IsUnicode ? "w": "" ) "printf"
 If ! FSz := DllCall( DLL "GetFileVersionInfoSize" CS , Str,peFile, UInt,0 )
   Return "", DllCall( "SetLastError", UInt,1 )
 VarSetCapacity( FVI, FSz, 0 ), VarSetCapacity( Trans,8 * ( A_IsUnicode ? 2 : 1 ) )
 DllCall( DLL "GetFileVersionInfo" CS, Str,peFile, Int,0, UInt,FSz, UInt,&FVI )
 If ! DllCall( DLL "VerQueryValue" CS
    , UInt,&FVI, Str,"\VarFileInfo\Translation", UIntP,Translation, UInt,0 )
   Return "", DllCall( "SetLastError", UInt,2 )
 If ! DllCall( HexVal, Str,Trans, Str,"%08X", UInt,NumGet(Translation+0) )
   Return "", DllCall( "SetLastError", UInt,3 )
 Loop, Parse, StringFileInfo, %Delimiter%
 { subBlock := "\StringFileInfo\" SubStr(Trans,-3) SubStr(Trans,1,4) "\" A_LoopField
   If ! DllCall( DLL "VerQueryValue" CS, UInt,&FVI, Str,SubBlock, UIntP,InfoPtr, UInt,0 )
     Continue
   Value := ( A_IsUnicode ? %StrGet%( InfoPtr, DllCall( "lstrlen" CS, UInt,InfoPtr ) )
         :  DllCall( "MulDiv", UInt,InfoPtr, Int,1, Int,1, "Str"  ) )
   Info  .= Value ? ( (InStr(StringFileInfo,Delimiter) ? SubStr( A_LoopField Sps,1,24 ) . A_Tab : "") . Value . Delimiter ) :
 } StringTrimRight, Info, Info, 1
Return Info
}

But the file name parsing as it stands doesn't recognize the retrieved version number. In the line 426 change I posted above I got partway there, but I have a long way to go.

[TheArkive]

@burque505
Here's the func i use in my ahk installer, and i find this works fine for any version of ahk:

Code: Select all

; =================================================================
; ahkProps := GetAhkProps(sInput)
;    Returns ahk properties in a Map().
;    > sInput assumes the following path format:
;    - X:\path\base_path\AhkName AhkVersion\[AHK_H subfolder\]AutoHotkey[type].exe
;    - [type] = A32 / U32 / U64 / 32 / 64
;
;    props: ahkProduct, ahkVersion, installDir, ahkType, bitness, exeFile, exePath, exeDir, variant
;
;    ahkprop key values:
;    - product = AHK / AutoHotkey / AHK_H / AutoHotkey_H ... however it is typed
;    - version = Ex:  1.1.32.00
;    - majVersion = first char of version
;    - type = Unicode / ANSI
;    - bitness = 32-bit / 64-bit
;    - installDir = base folder where Ahk2Exe and help file resides
;    - exeFile = full name of exe file
;    - exePath = full path to and including the exe file
;    - exeDir = dir exe is located in
;    - variant = MT for "multi-threading" or blank ("")


; sFile := FileSelect()
; If !sFile
    ; exitapp    
; SplitPath sFile, &_FileExt, &_Dir, &_Ext, &_File, &_Drv
; objShl := ComObject("Shell.Application")
; objDir := objShl.NameSpace(_Dir)
; objItm := objDir.ParseName(_FileExt)
; msgbox "Product Name:`t" objItm.ExtendedProperty("{0CEF7D53-FA64-11D1-A203-0000F81FEDEE} 7") "`r`n"
     ; . "File Desc:`t" objItm.ExtendedProperty("{0CEF7D53-FA64-11D1-A203-0000F81FEDEE} 3") "`r`n"
     ; . "Product Ver:`t" objItm.ExtendedProperty("{0CEF7D53-FA64-11D1-A203-0000F81FEDEE} 8") "`r`n" ; (not listed in propkey.h)
     ; . "Copyright:`t" objItm.ExtendedProperty("{64440492-4C8B-11D1-8B70-080036B11A03} 11") 
     
     
GetAhkProps(sInput) {
    If (!FileExist(sInput))
        return ""
    
    SplitPath sInput, &ahkFile, &curDir
    objShl := ComObject("Shell.Application")
    objDir := objShl.NameSpace(curDir)
    objItm := objDir.ParseName(ahkFile)
    FileDesc    := objItm.ExtendedProperty("{0CEF7D53-FA64-11D1-A203-0000F81FEDEE} 3")
    ahkVersion  := RegExReplace(objItm.ExtendedProperty("{0CEF7D53-FA64-11D1-A203-0000F81FEDEE} 8"),"\, ?",".")
    
    arr := StrSplit(FileDesc," ")
    ahkProduct := arr[1]
    bitness := (SubStr(ahkVersion,1,3) = "1.0") ? 32 : StrReplace(arr[arr.Length],"-bit","") ; thanks to use LBJ for this
    isAhkH := (ahkProduct = "AutoHotkey_H")?true:false
    ahkType := (arr.Length = 3) ? arr[2] : "Unicode"
    
    var := "", installDir := curDir
    
    If (InStr(sInput,"\Win32a_MT\"))
        installDir := StrReplace(installDir,"\Win32a_MT"), var := "MT"
    Else If (InStr(sInput,"\Win32a\"))
        installDir := StrReplace(installDir,"\Win32a")
    Else If (InStr(sInput,"\Win32w_MT\"))
        installDir := StrReplace(installDir,"\Win32w_MT"), var := "MT"
    Else If (InStr(sInput,"\Win32w\"))
        installDir := StrReplace(installDir,"\Win32w")
    Else If (InStr(sInput,"\x64w_MT\"))
        installDir := StrReplace(installDir,"\x64w_MT"), var := "MT"
    Else If (InStr(sInput,"\x64w\"))
        installDir := StrReplace(installDir,"\x64w")
    
    ahkProps := {exePath:sInput, installDir:installDir, product:ahkProduct, version:ahkVersion, majVersion:SubStr(ahkVersion,1,1)
               , type:ahkType, bitness:bitness, variant:var, exeFile:ahkFile, exeDir:curDir, isAhkH:isAhkH}
    
    If (ahkType = "" Or bitness = "")
        return ""
    Else
        return ahkProps
}

=========================================================================
EDIT: Just input an EXE to the func, and it spits out an obj with props about the exe
=========================================================================

Call me crazy, but i find that making minimal changes in the registry is slightly less problematic / invasive, as long as you know the changes being made, and what to expect of course.

The whole deal with the "old school" AHK setup is that AutoHotkey.exe was needed, which meant always making an extra copy of your "chosen version" ansi, unicode, 32-bit, 64-bit etc.

With the proper setup, making this extra copy is not necessary.

Another thing to consider, assuming you can get my switcher working as intended, is you can install AHK v1 (or ahk_h or whatever) as your base version, and use the #Requires directive in your newer (and hopefully fewer) ahk v2 scripts. Then no switching is necessary.

Using my installer, you can manually drop in AHK_H folders (with the proper contents of course) and then fire up my installer, then choose AHK_H as a base version as well. (Base version meaning, the one that is installed, and is run by default when no #Requires directive exists in the script.)

Using Notepad++ (or similar) you can make changes to your #Requires directives in mass, although this is an extra step not required with other methods. It still has the added benefit of no more moving/copying files or messing with registry.

It certainly depends on what you want to do, and how you want to do it. I'm afraid no one size fits all yet.

EDIT:

One case of editing the registry rather than "copying files" being "better" is in the case of changing info while a script is running. If a script is running and you change info in the registry with a switcher, then the running scripts are not bothered. If you do this while scripts are running and try to copy files, of course it either won't work, or you'll have to force quit those scripts.

Again, depends on what you want to do, and how you want to do it.

I also edited my previous long response listing detailed registry info that relates to the .ahk extension. I included a screenshot of the .ahk ext key being linked to a ProgID.

[burque505]

@TheArkive, I just ran your installer, selected a version (which worked this time), then immediately rebooted, as you suggested yesterday. I'm not running in portable mode, and I can switch easily now.

Also, I can still run AHK-EXE-Swapper to change the version that is used when running, for example, "C:\temp>autohotkey myscript.ahk".

I will see if this survives a reboot. EDIT: It survived a reboot. To summarize the steps I took:

A) Do not use 'Uninstall' from the GUI. Do not use Fully Portable Mode.
B) Settings as shown below.
1) Run AHK Portable Installer.exe.
2) Select at least one version.
3) Reboot.
4) After switching versions, shut down AHK Portable Installer.

C) If using Scite4AHK and leaving original AHK in C:\Program Files\AutoHotkey installed (works fine), rerun Scite4AHK setup if necessary (this time I did not need to).
D) Check to see there's a version available to run via the command line: C:\temp>where autohotkey

So far so good ...

settings.PNG (19.87 KiB) Viewed 3892 times

[TheArkive]

Man i forgot to mention that ... The closing it part. I guess it's time to change that. I meant for my script to be more intuitive than that.

One thing. I wouldn't recommend combining AHK Swapper and my script.

You should be able to change the active ahk version in AHK Portable Installer just fine (close it after making the change).

I'll modify it soon so closing is not necessary for changes to take effect. Or would you prefer a working version of AHK Swapper that doesnt have issues with AHK 2 exe?

I know i have some work to do to get my script to play nice with SciTE4AHK and VSCode as well...

Edit:

To be clear, i am glad you got it working! I'm just a little concerned over the combination of methods you are using.

[burque505]

I think the only reason I might leave it like I have it is because, after a swap with ahk-pi (if I've uninstalled AutoHotkey.exe, that is) then the .exe isn't in the path.
I know messing with the path can be perilous. I've had several open source projects (and even some commercial software) completely trash my path during installation.
Now I keep the path backed up (most of the time anyway...)
Thanks a million for all your help with this!

By the way, I got Ahk_H 2.0 beta.1 added as well, following your instructions.
Regards,
burque505

[TheArkive]

Cool man

Glad you got it set the way you want.

Let me know if theres something else i can work on to make a setup like yours easier. I have lots of ideas for future solutions (short term and long term), but can always use more input.

[burque505]

Well, if the path could be updated that would be great. Haven't really thought about long-term consequences, but it would be nice if the AHK version in the path (for command line use) matched the ahk-pi version loaded.
Thanks again!

[TheArkive]

That's an easy option to add. Thanks for the input!

Edit: you want the active version added to the path? Or the launcher exe added to the path? Launcher = AHK Portable Installer exe

[burque505]

I'm not sure if it would make a difference for me. Maybe an option to do either?

I just installed a VS Code extension for AHK, I actually kind of like how VS Code works with it. Seems to rely on a an AutoHotkey.exe being in the path. I don't know enough about it to know if its looking for a) an executable to run .ahk files (in which case the launcher would be fine) or b) looking for AutoHotkey.exe in the path. Probably the former, but I don't know. VS Code will run v2 scripts if I change the installed version to v2 with AHK-EXE-Swapper (I know, cringe-worthy), but not yet with just the launcher changing the version.

[TheArkive]

The launcher only automatically picks an exe based on #Requires directive. If you dont use that then no point to use the launcher.

Ok I'll add an option to add ahk exe / launcher exe to path.

[burque505]

Thank you! Not automatic is fine for my purposes, but I don't want you to go to any trouble. I could very easily be just an edge case.

[TheArkive]

I've seen many issues across the forum with trying to implement a particular setup. This happens to be one thing that i have yet to come across that is also very handy and easy to implement.

So no worries, I'm doing this for me too. I think a cli solution is handy for text editors like vscode, and the one I'm working on.

Many ideas rattling in my brain... We'll see what falls out first

[burque505]

[lexikos]

; . "Product Ver:`t" objItm.ExtendedProperty("{0CEF7D53-FA64-11D1-A203-0000F81FEDEE} 8") "`r`n" ; (not listed in propkey.h)

How'd you get the value, just out of interest?

I found the same - it wasn't listed in propkey.h, or anywhere else in the SDK, or in any lists I could find in the documentation.

I found System.Software.ProductName in some source code somewhere (and then in propkey.h), and added 1 to the PROPID (7) as my first guess, successfully retrieving the product version.

So then I thought, why not guess the canonical name too? System.Software.ProductVersion works.

[TheArkive]

@lexikos

Ironically, I did the same on my end, but the other way. I guessed the propID numerical value. #8 happened to be missing with the list I had, so I tried several propID numbers (#8 was one of them) to see what I could get. Some of them seemed to be repeat values or blank, but #8 was definitely unique.

I didn't think about guessing the name the way you did.

EDIT:

This "gap" in the propID list I refer to came from when I filtered all the propID's for that specific UUID. I noticed there were a few different UUIDs that encompassed all the properties, but {0CEF7D53-FA64-11D1-A203-0000F81FEDEE} either had more, or had more of the ones I was after. After coming up with this "filtered list", I then noticed a few missing numbers, and again #8 was one of the missing numbers... that was essentially my process.