AHK Portable Installer v1.29

[DaveT1]

Again, thank you so much for the reply and most helpful pointers

Just a minor correction. Admin privileges are actually not required, unless you select to install the registry keys into HKEY_LOCAL_MACHINE. The default is HKEY_CURRENT_USER and this requires no admin permissions. Having said that, it's good that you have admin rights, simply because AHK is more flexible with admin rights.

OK, learning lots here - I think I assumed admin rights were needed for any changes to the registry ! But, at least for me, it seems I do need to run AHK PI as an administrator in order to install?

You answer actually answers my question The fact you can't run ahk scripts with a double click indicates the entire ahk association is definitely broken, thus no context menus as well.

Glad to have answered the Q, even inadvertently .

Regarding install / uninstall for AHK Portable Installer...

OK, so this it what I did and found:

So, when I run AHK PI uninstall, restart my computer and then manually inspect the registry, I found:

• HKEY_CURRENT_USER\SOFTWARE\AutoHotkey absent
• HKEY_CURRENT_USER\SOFTWARE\Classes\AutoHotkeyScript absent
• HKEY_CURRENT_USER\SOFTWARE\Classes\.ahk absent
• HKEY_LOCAL_MACHINE\SOFTWARE\AutoHotkey absent
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript absent
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ahk absent

ie., the registry in these locations had no ahk entries.

I then run AHK PI install, restart my computer and then manually inspect the registry, and I find:

• HKEY_CURRENT_USER\SOFTWARE\AutoHotkey present
• HKEY_CURRENT_USER\SOFTWARE\Classes\AutoHotkeyScript absent
• HKEY_CURRENT_USER\SOFTWARE\Classes\.ahk absent
• HKEY_LOCAL_MACHINE\SOFTWARE\AutoHotkey present
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript present
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ahk present

But a double click on a .ahk file still opens it in Scite4AHK (not runs the script as had been the previous behaviour), and there are no ahk entries in the context menu.

I have experienced, that at some point Windows might decide the user has already "chosen" a program to handle the .ahk extension. And subsequent attempts to change the handler of the .ahk extension might cause Windows to intervene. Usually you will see intermittent prompts from windows to choose a program to handle .ahk files. They might seem to be somewhat random.

I have actually not experienced this in a while, and I also use admin rights on my computers. So I'm not so sure you are experiencing this kind of issue, but it's something to keep in mind.

Ah, thank you for this point.

---

So, AHK PI uninstall / install is making changes to the registry, but maybe there is something else going on to make my system screwy?

As ever, very grateful for your time and help.

[TheArkive]

Ok check HKEY_LOCAL_MACHINE\Software\Classes ... Something must have put .ahk file type in there. Manually delete it. If you don't see it there then check HKEY_CLASSES_ROOT. That entry is already in the registry, which is why it wont appear in HKCU.

As an alternative, you can also try running AHKPI as admin and then click uninstall. That should work. In any case check those other registry locations. I'm sure .ahk already exists somewhere. So run AHK PI as admin and try uninstall again, and check the other locations for .ahk, and make sure it is gone, THEN reinstall.

Sidenote

Ya need admin rights to write to / delete from HKEY_LOCAL_MACHINE. So if you tell AHK PI to install for the machine, and not the current user, THEN you will need admin rights.

I think your issue is related to what lexikos said about SciTE a few posts ago.

[DaveT1]

OK, I only just saw Lexikos' post and yours too. Out all day, but will look at both later and report what I find.

Thank you so much.

[lexikos]

I have experienced, that at some point Windows might decide the user has already "chosen" a program to handle the .ahk extension. And subsequent attempts to change the handler of the .ahk extension might cause Windows to intervene.

If you ever use Explorer, Control Panel or Settings to change the default program for a file, the setting is recorded for the current user, under a key like the following:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.ahk\UserChoice

If you install AutoHotkey v2.0-beta.9 and this setting is pointing to something other than AutoHotkeyScript, setup will alert you and offer to rectify it.

More off-topic

The UserChoice ProgId value is protected by access controls and a hash - Microsoft try to make it difficult for programs to set themself as the default, causing various sorts of stupidity, like:

• Programs (made by Microsoft) that ask if you want to set them as default, then when you say yes, tell you to go into Settings and do it yourself.
• Programs that offer a "set as default" button that just launches the Settings app.
• Programs that display a file's Properties dialog and tell you to click the Change button.

Usually you will see intermittent prompts from windows to choose a program to handle .ahk files. They might seem to be somewhat random.

In my experience, these prompts appear for any file type which has new programs registered for "open with". Generally at least one of the items in the "open with" list will have the text "new" under it, but it's easy to miss. Windows records which apps the user has "seen" under the following key:
HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts

[TheArkive]

Thanks again for the input @lexikos for the input.

I had somehow not thought of checking the registry before installation I'll make that change.

It may be about time to retire this project

EDIT:

And yes, I do remember the whole "UserChoice" thing. That was a pain in my backside for a while.

[TheArkive]

@DaveT1

I'll modify the list of reg keys to check, thanks to Lexikos' input:

Code: Select all

HKEY_CURRENT_USER\SOFTWARE\AutoHotkey
HKEY_CURRENT_USER\SOFTWARE\Classes\AutoHotkeyScript
HKEY_CURRENT_USER\SOFTWARE\Classes\.ahk
HKEY_LOCAL_MACHINE\SOFTWARE\AutoHotkey
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AutoHotkeyScript
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ahk

; If you find .ahk here, I suggest try to delete it.  You might need admin permissions to permanently delete it.
; Windows has a tendency to restore values that are changed/removed (if I remember correctly)
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.ahk

If you have ever answered a prompt that asked you "what program" you want to use to open AHK files with, then the .ahk key should exist in one of the ...\Software\Classes keys, and will also likely exist in ...\Explorer\FileExts, and will have the UserChoice subkey as well, recording a hash that represents your interaction with the prompt, and hence your "choice".

As lexikos mentioned, the Open With dialog plays a role here.

---

If you have seen this "Open With" dialog, that appears to be from Windows, asking you to pick a program for opening ahk files, you will want to read this.

The curse of "Open With"...

I mischaracterized these prompts as "intermittent" in a previous post. I remember (now that I'm thinking back to these struggles) that I was able to determine the main cause of these prompts was a result of me having made adjustments to the script path/exe, which needs to subsequently be reflected in the registry.

In short, if you have moved the AHK PI folder without clicking Install again to update the registry, then you will absolutely get this "Open With" prompt, simply because Windows can not find the specified exe. I have also seen these prompts when double-clicking on a file that is NOT registered on the system. Then Windows will ask what program you want to use. Of course if something went wrong and Windows "thought" that the .ahk extension was not registered, then this would be another scenario where you would see this dialog.

In any case, if you see this "Open With" dialog in the future pertaining to AHK, it means something is already wrong, and trying to select an AHK exe from this dialog will not fix the problem the way you want. Especially considering using AHK PI and the legit installer for AHK v2 both operate in a way that manages multiple versions of AHK. So the "real" install method must be used in either case (AHK PI or legit v2 installer), and the "Open With" dialog will certainly interfere with this setup.

If you see this dialog, take a step back, and uninstall / reinstall ... with or without reboot is your choice. I have not needed to restart my system after clicking Install in a while, unless I'm doing a fresh install on Windows and setting up the .ahk extension for the first time on the system. That is the only case I have ever needed to restart. In all other cases I can update the registry without a restart after updating to a new version of AHK through the UI.

And of course the new installer for AHK v2 basically does much of the same as AHK PI, but in a few ways definitely better at this point.

Thanks again @lexikos for your input. I'll be making some changes now!

---

If you end up needing help with SciTE4AHK again after fixing this file type issue (god willing), then post again and we'll pick up where we left off.

[DaveT1]

OK, this is the progress I've made

As an alternative, you can also try running AHKPI as admin and then click uninstall. That should work. In any case check those other registry locations.

Yep that worked and seems to have successfully removed any reference to autohotkey from those 9 registry locations.

THEN reinstall.

So, before doing an AHK PI install, I changed 2 AHK PI settings: Install for: from All Users to Current User, and changed Text Editor: from Scite4AHK to Notepad++. Then reinstalled and restarted. Then I only have autohotkey references in HKEY_CURRENT_USER, and no reference to autohotkey in HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT.

But still 'screwy' behaviour - ie., double-clicking a .ahk file opened it in Scite4AHK and no context menu entries for autohotkey.

Sidenote: Ya need admin rights to write to / delete from HKEY_LOCAL_MACHINE. So if you tell AHK PI to install for the machine, and not the current user, THEN you will need admin rights.

Brilliant - the stuff I'm learning

I think your issue is related to what lexikos said about SciTE a few posts ago.

OK, so I read through Lexikos' post and link in more detail. Most over my head. But after a bit of trial and error, then (paraphrasing Lexikos)

Normalcy returns ....:

• ...
• ...
• ...
• Open-with AutoHotkey, of course.
• ...

That is, .ahk files once again become associated with AutoHotkey and all of the normal context menu options return.

this seemed to nail it for me - specifically I right click on my .akk file and do Open with | Choose another app then check the Always use this app to open .ahk files option and then select AutoHoykey 64-bit. And now this file runs with a double-click, and, as it's in my start-up folder, launches automatically when I restart my laptop. And my autohotkey-specific entries in the context menu have re-appeared.

So I think that this might all have stemmed, not from a Windows update, but from an earlier time when, in AHK PI, I changed (not thinking twice about it and not recalling until now !!), the default text editor to Scite4AHK. So I guess that this initiated the issue, but without me realising it was a Scite4AHK matter and not related to one of the numerous Windows updates I seem to have had recently.

I only occasionally use Scite4AHK for quick checks on scripts. I mainly use vscode for anything more chunky. So I guess for now I should avoid using Scite4AHK until the next update.

Wow, you have again been so patient...I have to confess there were a couple of moments there when I was ready to quit AUTOHOTKEY!! So glad you and LexiKos helped me through. Please have some and as much as you want on me!

[DaveT1]

I'll modify the list of reg keys to check, thanks to Lexikos' input:

That sounds like a win, but hope your time helping my trials was worth it

As lexikos mentioned, the Open With dialog plays a role here.

As I just posted above, this, together with stopping the use of Scite4AHK, seems to have fixed it for me

If you end up needing help with SciTE4AHK again after fixing this file type issue (god willing), then post again and we'll pick up where we left off.

I think that I'm all good for now. Again, many thanks for all your time and effort - not only have I fixed my problem, but I've learnt lots too

[TheArkive]

@DaveT1

I'm glad you got it working, but I think you misunderstood that post. And I was actually referring to this post by lexikos just a few posts above (and don't forget the spoiler).

I'll explain more later, after I've done some testing. In the meantime you may want to read the above link from lexikos more carefully, as well as my post here (also a few posts above) ... specifically in the The curse of 'Open With' spoiler.

This will likely cause issues if you try to update ahk again via AHK PI interface.

I'll be borrowing a fix from @lexikos (thanks again!) that will undo the results of this "Open With" dialog.

This will be in the next version of AhK PI.

EDIT:

The context of "normalcy returns" here is only relating to the path of least resistance. Not an actual fix.

Simply put, "Open With" and the resulting "UserChoice" reg key makes life more difficult. It should be undone for easy and normal operation of AHK, even if not using AHK PI.

[TheArkive]

v1.26

• added a check for UserChoice reg key, prompts user to optionally remove it
• minor readme update to clarify a few things about disabling UserAccountControl (if desired)

Public Service Announcement...

Installers can be complicated. My version of this "installer" had a shortcoming that is now fixed.

In short, if you see the "Open With" window asking you to specify a program to use to open .ahk files, then something is broken. Especially if you did not invoke the "Open With" dialog manually from the context menu.

Also, if you manually invoke "Open With" and check the "always use" checkbox, then you are breaking the functionality of the installer (for AHK PI and v2 installer).

To restore the normal file associations, and to ensure that AHK PI is able to continue to normally manage/update your versions of AHK and dynamically launch your scripts with the proper version, follow these steps with the updated AHK PI v1.26:

1. Click Uninstall
   - If you selected to install for "All Users", then you may need to run AHK PI as admin to do a proper full uninstall.
   - If the UserChoice key exists, you will be prompted to delete it.
2. Modify the settings in AHK PI as desired, including your desired text editor.
3. Select your desired of version of AHK and click the Install button.

You should be back to normal now. To be extra sure of this, make sure the UserChoice subkey does not exist in the following location:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.ahk\UserChoice

A little extra info...

The potential madness that can result from defining the .ahk file association using "Open With" is explained by lexikos in the following posts:

• S4AHK takes over .ahk file association
• Reply to: AHK Portable Installer

Fortunately, admin rights are not needed to correct this. And of course if you don't use the "always use" checkbox, then you should be able to populate the "Open With" context menu with all the programs you desire, without destroying the normal functionality of AHK PI (this also goes for the legit AHK v2 installer as well).

Special thanks to lexikos for informing me of this fix.

Special thanks to DaveT1 for his frequent posts and detailed descriptions, which made it possible to readdress this issue with AHK PI and construct a fix.

[TheArkive]

v1.27

• improved sorting of main list
• improved execution of #Requires directive
• added "match" option for #Requires
• updated readme

[TheArkive]

v1.28

• fixed execution of #Requires directive to filter by major version, as is done by AHK
• fixed execution of "match" option
• updated readme

[TheArkive]

v1.29

• now checking 'tag_name' in github output instead of 'name' for version info
• when changing from UPX platform from/to win32 <-> win64, and then clicking "Check for Updates", the proper platform will be downloaded.
• changed default UPX platform to win64
• added an update check after switching the UPX platform for download, in order to update the URL when the download happens

This update also addresses the recent (or maybe not so recent) disappearance of the reported UPX version.