Installing Version 2

Get help with using AutoHotkey (v2 or newer) and its commands and hotkeys
jwinfl
Posts: 86
Joined: 16 Aug 2017, 12:37

Installing Version 2

Post by jwinfl » 23 Sep 2022, 10:54

I went to install v2 because I read it would not effect my v1.1
I get these windows...
image.png
image.png (34.75 KiB) Viewed 3325 times
I'm not sure what the cryptic setup window is saying, specifically; "will not be integrated" and "its registration will be overwritten"?
I want to use v1.1 most of the time and v2 some of the time.
I planned on registering ".ahk2" extensions as v2 scripts.
An explanation would be greatly appreciated.
Thank you

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Installing Version 2

Post by lexikos » 24 Sep 2022, 00:20

In short: Install it into the same directory as v1 and use the .ahk extension for both versions.


All versions of AutoHotkey are designed to use the .ahk extension. This works best if they are integrated into one package. Leaving them separate could mean:
  • When you install one version, it takes over the .ahk file type and the other version stops working - the registration is overwritten.
  • When you uninstall one version, it unregisters the .ahk file type and the other version won't work (but perhaps it wasn't working in the first place).
  • More complicated code to - only partially - avoid the above issues, without any real benefit.
If you install v2 with the recommended options (i.e. just click Install), everything will go into one directory, and you will be able to launch scripts with whichever version you prefer, or whichever version each script requires.

There are multiple options for how .ahk scripts will run:
  • The default option is to let the launcher choose the version automatically based on syntax or #Requires, or prompt the user if automatic detection fails.
  • Syntax detection can be turned off, in case it doesn't work as intended.
  • The launcher can be set to prefer either v1 or v2 if the version can't be determined, instead of prompting.
  • Scripts can be set to run with a specific exe, disabling all launcher functions.

I do not recommend or support using a separate extension. You can obviously register whatever extension(s) you want, but you will have to do it manually. If you are doing that, you should probably avoid using the installer.

I read it would not effect my v1.1
I would be interested to know what you read and where.
I'm not sure what the cryptic setup window is saying
Now that you mention it, I agree it is cryptic and plan to revise it.

jwinfl
Posts: 86
Joined: 16 Aug 2017, 12:37

Re: Installing Version 2

Post by jwinfl » 24 Sep 2022, 04:42

@lexikos,
Thank you for the information.
I looked at several dozen posts and websites, unfortunately I don't remember which ones said what. I do remember many of them recommended using the .ahk2 script extension.
Your post above clarifies the matter pretty well.

================================================================
I will be using v1.1 for the foreseeable future except when I am trying v2.
================================================================

I do have a few questions, keeping my usage in mind...

1. After I install v2 should I add #Requires (v1) to my existing v1.1 scripts?
2. You stated "When you install one version, it takes over the .ahk file type and the other version stops working - the registration is overwritten." what does version mean, I assume you are referring to non-ahk file extensions and not ahk v1.1?
3. v2 tries to install in the v1 directory, should I install it in a different directory or does it matter?
4. How do I set the launcher to "prefer" v1?
5. How do I set a script to run with a specific exe, eg, v1?

Lastly, I just want to make sure that installing v2 will not effect my continued use of v1.1.?

Your response will be appreciated.

User avatar
boiler
Posts: 16706
Joined: 21 Dec 2014, 02:44

Re: Installing Version 2

Post by boiler » 24 Sep 2022, 07:58

jwinfl wrote: 2. You stated "When you install one version, it takes over the .ahk file type and the other version stops working - the registration is overwritten." what does version mean, I assume you are referring to non-ahk file extensions and not ahk v1.1?
By version, he means v1 or v2. And you are reading from the part of his post where he describes what would happen if you go against his recommendation and install each version in a separate directory. Install them in the same directory to prevent what he described from happening.

jwinfl wrote: 3. v2 tries to install in the v1 directory, should I install it in a different directory or does it matter?
It does matter, and that was the point of most of his post — to explain why they should be installed in the same directory. It’s the very first thing he said.

jwinfl wrote: Lastly, I just want to make sure that installing v2 will not effect my continued use of v1.1.?
Then do what he recommended and install v2 in the same directory as v1.

jwinfl
Posts: 86
Joined: 16 Aug 2017, 12:37

Re: Installing Version 2

Post by jwinfl » 24 Sep 2022, 10:52

@boiler,

Thank you for the clarification.

I will install v2 in the same directory as v1.

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Installing Version 2

Post by lexikos » 25 Sep 2022, 03:11

You stated "When you install one version, it takes over the .ahk file type and the other version stops working - the registration is overwritten."
Perhaps it would have been clearer to say:
When you install AutoHotkey in a new directory, it takes over the .ahk file type and any other previously existing installation of AutoHotkey stops working.

This is regardless of which version you are installing and which version is already installed. The installers aren't designed to handle this in any way, other than the v2 installer showing a warning.
How do I set the launcher to "prefer" v1?
After installation, the "dash" appears automatically (if you closed it, Dash explains how to open it). Select "Launch settings". For your case, I would recommend leaving it on "Auto-detect" (so that you can run v2 scripts) and selecting "Use v1.x" under "When detection fails".

Or you can just use the default settings, which I recommend in general, otherwise I would have designed it to set different default settings.
How do I set a script to run with a specific exe, eg, v1?
As I said, the launcher chooses the version based on #Requires and syntax detection. Most v1 scripts will automatically run with a v1 interpreter. If you have some that do not, you can either add #Requires or change the "When detection fails" setting as described above.

Preferences for Unicode vs. ANSI or 32-bit vs. 64-bit cannot be set by the script yet, but can be set for v1 scripts and v2 scripts independently, in the "Launch settings". It is designed this way (rather than selecting one or two exe files) so that:
  • If the script has a #Requires directive that requires a newer version than your default version (e.g. a pre-release version), the launcher will be able to select the appropriate exe.
  • The launcher settings do not need to be adjusted when a new version is installed (if "Latest 1.x" and/or "Latest 2.x" are used).
  • Swapping between versions is just a case of selecting the version number from a list.
  • The appropriate exe can be selected by the launcher if/when you select the "Run with UI access" context menu option.

jwinfl
Posts: 86
Joined: 16 Aug 2017, 12:37

Re: Installing Version 2

Post by jwinfl » 25 Sep 2022, 04:59

@lexikos,

Thank you for the clarifications.

User avatar
FanaticGuru
Posts: 1905
Joined: 30 Sep 2013, 22:25

Re: Installing Version 2

Post by FanaticGuru » 03 Oct 2022, 16:15

lexikos wrote:
24 Sep 2022, 00:20
I do not recommend or support using a separate extension. You can obviously register whatever extension(s) you want, but you will have to do it manually. If you are doing that, you should probably avoid using the installer.

Although not recommended or supported, it is very doable.

I played around with v2 about two years ago but recently decided to try it again for real scripts that I use. I really like the more consistent syntax. It looks like it is just going to be better all round, once I get past the initial re-learning curve. I appreciate the work @lexikos and other contributors have put into moving AHK into the future.

Also, SciTE4AutoHotkey was recently updated. So, I decided to do a clean new install of both AutoHotkey and SciTE4AutoHotkey. I had tinker with both in ways I probably do not even remember so I uninstalled and removed everything I could to try to get back to a clean slate.

I installed both as recommended. Everything seemed to work great. I really like the effort with the Dash and Launcher. Good to see effort being put into some of these supporting type programs to form a more complete package. Vanilla SciTE4AutoHotkey also seems to work pretty good except for no Calltip help for functions and commands. Also, miss not having the AutoComplete for variable names but that was a mod. But overall SciTE4AutoHotkey has had some pretty nice upgrades including more support for AHK v2. Hopefully the Calltip will get fixed as that was a real time saver as I often have to look up the parameters and order.

The Launcher is a pretty cool idea. I can see how it could really help with the adoption of v2 as everyone can have v1 and v2 both installed and then just download or copy code from the forum or wherever and AHK will use the right version to run it. And since most people would have both installed, posting v2 code would not seem like a barrier to using it. It makes for an easy gradual transition at a pace that is comfortable for both creators and users. Then at some point v2 would become the predominant version in an organic way.

As clever as the Launcher is, it does not handle this:

Code: Select all

Run Test.ahk,,,PID
MsgBox % PID
WinGetTitle, Title, ahk_pid %PID%
MsgBox % Title
Basically, because scripts are run through the launcher you do not get the PID of the actual script. At least not in my limited testing. This breaks a major script that I use extensively, AKH Startup.

So, I had to resort to not using the Launcher and use separate extension for v1 and v2. I modified the Registry to support ahk and ah2 extensions with context menus for each which was not too hard. I added this to SciTE4AutoHotkey's ScitEUser.properties:

Code: Select all

file.patterns.ahk=*.ahk;*.ah2
file.patterns.ahk1=*.ahk
file.patterns.ahk2=*.ah2

ah2.file.extension=*.ah2
filter.ahk=\
AutoHotkey scripts (*.ahk)|$(ahk.file.extension)|\
AutoHotkey v2 scripts (*.ah2)|$(ah2.file.extension)|\
AHK scriptlets (*.scriptlet)|$(ahkscriptlet.file.extension)|

So far, I am very pleased with this slightly modified installation of AutoHotkey v1, v2 and SciTE4AutoHokey. Clean installs and about 15 minutes of manual tinkering will get two extensions working pretty well.

I don't know if there is any way to get the Launcher to report the PID of the script back to the Run command. I assume I could have the Run use a specific AutoHotkey.exe but that kind of defeats the purpose of having v1 and v2 intermingle without having to worry about which exe needs to run each. If I rewrite AHK Startup to v2, I will put some though into it.

Also, separate extensions do make organizing my files easier and different icons. Even with the benefits of separate extensions, I would probably use the Launcher and one extension if it did not break a major script I use.

FG
Hotkey Help - Help Dialog for Currently Running AHK Scripts
AHK Startup - Consolidate Multiply AHK Scripts with one Tray Icon
Hotstring Manager - Create and Manage Hotstrings
[Class] WinHook - Create Window Shell Hooks and Window Event Hooks

TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Installing Version 2

Post by TAC109 » 03 Oct 2022, 17:21

@FanaticGuru
As clever as the Launcher is, it does not handle this:

Code: Select all

Run Test.ahk,,,PID
MsgBox % PID
WinGetTitle, Title, ahk_pid %PID%
MsgBox % Title
You should be able to solve this problem by avoiding the launcher (untested):

Code: Select all

Run "%A_AhkPath%" Test.ahk,,,PID
MsgBox % PID
WinGetTitle, Title, ahk_pid %PID%
MsgBox % Title
Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Installing Version 2

Post by lexikos » 03 Oct 2022, 19:39

FanaticGuru wrote:
03 Oct 2022, 16:15
As clever as the Launcher is, it does not handle this:

Code: Select all

Run Test.ahk,,,PID
MsgBox % PID
WinGetTitle, Title, ahk_pid %PID%
MsgBox % Title
The script needs to handle the possibility of the launcher, because it can't work the other way around. It is similar to "running" a document that opens in an existing instance of an application (e.g. Word or Excel), where you only get the PID of the process that sends a message to the existing instance.

There are some more potential solutions:
  • Wait for the (new) Test.ahk ahk_class AutoHotkey hidden window to exist.
  • Implement a switch in the launcher to pass back the new PID, such as via the exit code.
  • Implement a switch in the launcher to pass back the appropriate interpreter or command line to launch the script. Tools and scripts can use the launcher explicitly to determine how to run a script. (Sometimes it is useful to know the command line for later use; for example, shell verbs in the registry require a proper command line, not just the path of a script.)
A separate extension is not very forward-thinking. The launcher will handle v2.1.alpha in a way that allows you to continue running v1.0 and v2.0 scripts, but still allow running scripts that explicitly #require v2.1-alpha. Then when v3 comes around, you won't need another filename extension.

The launcher may also gain the capability to specify within the script how it should be launched (32/64-bit, ANSI/Unicode, UIA or not, admin or not).
I don't know if there is any way to get the Launcher to report the PID of the script back to the Run command.
Not yet.
This breaks a major script that I use extensively, [AHK] Startup.
Without the launcher, AHK Startup will either only work with scripts written for one build/version of AutoHotkey (for each registered extension), or it will need its own version-selection logic. It sounds like the sort of script that might benefit from explicitly supporting the launcher.

safetycar
Posts: 435
Joined: 12 Aug 2017, 04:27

Re: Installing Version 2

Post by safetycar » 03 Oct 2022, 23:25

The use of the variable A_AhkPath like suggested by @TAC109 does the trick if you are relaunching scripts that use the same version. It's what I used to quick fix some things that weren't working at the time of the introduction of the launcher.

User avatar
FanaticGuru
Posts: 1905
Joined: 30 Sep 2013, 22:25

Re: Installing Version 2

Post by FanaticGuru » 04 Oct 2022, 01:37

lexikos wrote:
03 Oct 2022, 19:39
The script needs to handle the possibility of the launcher, because it can't work the other way around. It is similar to "running" a document that opens in an existing instance of an application (e.g. Word or Excel), where you only get the PID of the process that sends a message to the existing instance.
I knew I could do the Run "%A_AhkPath%" Test.ahk,,,PID thing and just tell it which version to use, the default being the version of the script doing the Run. Or the user in their script list definition could put a flag of some sort to tell AHK Startup which version to use. That is not very cool though.

lexikos wrote:
03 Oct 2022, 19:39
There are some more potential solutions:
  • Implement a switch in the launcher to pass back the new PID, such as via the exit code.
  • Implement a switch in the launcher to pass back the appropriate interpreter or command line to launch the script. Tools and scripts can use the launcher explicitly to determine how to run a script. (Sometimes it is useful to know the command line for later use; for example, shell verbs in the registry require a proper command line, not just the path of a script.)
This is much cooler. If the launcher had some switches to send the PID back through the exit code, or the path through some means, or to just send the path without actually running it, or command line; more switches more fun. Maybe some future features since the launcher is bundled with AHK and does not do much good to just change my version. Some additions in this area would be really great for the launcher. It seems like implementing a variety of switches would not be that hard for someone that knows what they are doing. I also thought about a function version of the launcher that I could put in my script. When I went to look at the launcher code to see about converting at least the part that finds the path and version of AHK to use, it was more complex than I would have guessed.

lexikos wrote:
03 Oct 2022, 19:39
A separate extension is not very forward-thinking. The launcher will handle v2.1.alpha in a way that allows you to continue running v1.0 and v2.0 scripts, but still allow running scripts that explicitly #require v2.1-alpha. Then when v3 comes around, you won't need another filename extension.
I agree the launcher is much more forward-thinking and is a good idea. I probably should have thought about it a bit before taking the two-extension route as soon as I encountered a problem. It just made me gun-shy about what else it might break. Now that I think about it posting a AHK Startup that will not work with the standard installation is not good. If I am going to post anything that I am half-way proud of then it needs to work for the standard installation. The two-extensions really only solved the problem for me. I need to think about this more.

FG
Hotkey Help - Help Dialog for Currently Running AHK Scripts
AHK Startup - Consolidate Multiply AHK Scripts with one Tray Icon
Hotstring Manager - Create and Manage Hotstrings
[Class] WinHook - Create Window Shell Hooks and Window Event Hooks

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Installing Version 2

Post by lexikos » 04 Oct 2022, 23:04

Using command line switches requires locating the launcher somehow. AssocQueryString can be used to determine whether the launcher is associated with .ahk files and (if so) its location.

Of course, it's not difficult to get the installation directory from the registry (although it could be under HKCU and/or HKLM) and append "\UX\launcher.ahk".

Another option would be for the installer to register additional shell verbs. For example, we already have Run '*compile Script.ahk'. A verb like "launch" or "identify" would allow a script to invoke the launcher even if the default verb is not associated with the launcher (such as if it was disabled via the launcher settings GUI). These verbs can be hidden to avoid cluttering the Explorer context menu.

Post Reply

Return to “Ask for Help (v2)”