AHK Portable Installer v1.29

Post your working scripts, libraries and tools for AHK v1.1 and older
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.17

Post by TheArkive » 24 May 2021, 06:57

Changes for v1.17
  • EXE file version info now taken directly from the EXE in most cases. AHK_H still requires the original folder structure to differentiate between "MT" and "standard" versions. Directory layout is generally the same, but the naming convention is now much less strict.
  • When choosing your base version, a copy of the EXE renamed to "AutoHotkey.exe" is no longer done automatically. This is in line with how AHK v2 a136+ will be compiled (this feature may come back - depending on how Ahk2Exe developments go).
  • For the latest test build of `Ahk2Exe` that conforms to the latest features/requirements of AHK v2 a136+ go here.

For notes on this test release of Ahk2Exe, see this post.

User avatar
lmstearn
Posts: 688
Joined: 11 Aug 2016, 02:32
Contact:

Re: AHK Portable Installer v1.17

Post by lmstearn » 06 Jul 2021, 11:16

Hey, this is a very interesting project, so thanks for the script.
A bit of a hiccup in the basic setup phase, unfortunately, with
AutoHotkey version mismatch! Please reinstall!
Using the 64 bit from AutoHotkey_2.0-a138-7538f26f, with standard 1.1.33.09 installation.
Checked the directory requirements, for the default basic setup, and created a subdirectory for v2 as per your docs.
Changing to Fully portable mode makes the mismatch error go away, but a few other things don't work.
The help button doesn't produce a dialog, the Window Spy button won't run the WindowSpy.ahk script copied to the PI directory, the compiler button produces:
Error: This value of type "String" has no property named "__Item".
Line#
348: Else
349: oGui.Show("w480 h500"), Settings["toggle"] := 1
351: }
351: Else
351: If (oCtl.Name = "Compiler")
351: {
352: ahkProps := GetAhkProps(Settings["ActiveVersionPath"])
---> 353: Run(ahkProps["installDir"] "\Compiler\Ahk2Exe.exe")
355: }
355: Else
355: If (oCtl.Name = "ActivateExe" or oCtl.Name = "ExeList")
355: {
356: ActivateEXE()
358: }
358: Else
There's a similar error with Activate Exe, but only working with AHK scripts at this stage.
Must have missed something fundamental here, if you could point out where it's wrong that would help greatly.
Thanks.
:arrow: itros "ylbbub eht tuO kaerB" a ni kcuts m'I pleH

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.17

Post by TheArkive » 06 Jul 2021, 11:56

@lmstearn
So, you are trying to use fully portable mode? Or not?

From looking at the error, the exe you are trying to use doesn't seem to have Ahk2Exe in the compiler folder. But that has nothing to do with running scripts, only compiling. And actually a138 has no compiler at the moment, but lexikos has released a test build of Ahk2Exe that will do command line compiling.

The help button is supposed to open the help file for the active version of AHK.

Which version of WIndow Spy are you using? If you can show me a screenshot of the a138 folder (or a file list).

What stuff exactly doesn't work in fully portable mode? Just about everything should work, but it will be different. Ya gotta use the shortcuts for running scripts in explorer windows, ie. middle click on a SELECTED file to run it, not double-click.

EDIT:

If you like, we can arrange a time on IRC or Discord and then we can employ screeshots and real-time back-and-forth to get it up and running. Since you are trying to use this alongside a legit install of AHK v1, i suspect there may be other potential issues if you don't use Fully Portable mode.

I admit some aspects of my instructions either need more explanation, or already have too much explanation. I'm happy to get feedback to improve this script.

User avatar
lmstearn
Posts: 688
Joined: 11 Aug 2016, 02:32
Contact:

Re: AHK Portable Installer v1.17

Post by lmstearn » 07 Jul 2021, 09:06

Thanks for the response- we'll get it on the rails now the brainfog has gone! :)
TheArkive wrote:
06 Jul 2021, 11:56
@lmstearn
So, you are trying to use fully portable mode? Or not?
Actually, both- the default is the non-fully portable so it's more critical. Shall we focus on this for now?
From looking at the error, the exe you are trying to use doesn't seem to have Ahk2Exe in the compiler folder. But that has nothing to do with running scripts, only compiling. And actually a138 has no compiler at the moment, but lexikos has released a test build of Ahk2Exe that will do command line compiling.
Cool, that is well documented. Maybe as a an additional feature, the command line compiling can be endowed with a gui frontend once it is merged with the alpha.
Ahk2Exe (v1) certainly lives in the compiler folder in the default Program Files (Admin accessed) location.
The help button is supposed to open the help file for the active version of AHK.
There's no error when the button is clicked, however the unblocked help file won't open either.
Which version of WIndow Spy are you using? If you can show me a screenshot of the a138 folder (or a file list).
Sure thing: D/L the png, as it doesn't display well in the 1drv web interface: https://1drv.ms/u/s!Ak71HCtdvRa9gupWupFLLkxIftaFbQ?e=FB18X8 (attachments here are temp broken).
It's the script from the other thread here, not au3_spy.exe, however. Seems likely one has to compile the v2 Window Spy.ahkwith lexikos's test build to get au3_spy.exe.

Code: Select all

; 
; Window Spy for AHKv2
;

#NoTrayIcon
#SingleInstance Ignore
SetWorkingDir A_ScriptDir
CoordMode "Pixel", "Screen"
What stuff exactly doesn't work in fully portable mode? Just about everything should work, but it will be different. Ya gotta use the shortcuts for running scripts in explorer windows, ie. middle click on a SELECTED file to run it, not double-click.
Noted. :)
If you like, we can arrange a time on IRC or Discord and then we can employ screeshots and real-time back-and-forth to get it up and running. Since you are trying to use this alongside a legit install of AHK v1, i suspect there may be other potential issues if you don't use Fully Portable mode.

I admit some aspects of my instructions either need more explanation, or already have too much explanation. I'm happy to get feedback to improve this script.
Thanks, if it get's too much in the way of the thread, raising a Github issue might work just as well, as my hours in front of the screen are, at best, ragtime.
Here are some further obs:

-The Check Updates Now button doesn't produce any dialog- is that intentional?

-Does clicking or selecting anything in the launcher list perform an action? There is:
In non-portable mode, when you click Activate EXE, or double-click on a version in the list,
If that refers to the main list at the top of the gui, it only ever shows as empty. :(

-Still haven't got much idea of how to switch back to v1 through the PI gui, but that's probably due to other issues clouding the view.
Automating the copy sequence for AHK Portable Installer.exe to enable switching between versions might be a bit tricky to implement, but would certainly reduce the possibility of user error.
:arrow: itros "ylbbub eht tuO kaerB" a ni kcuts m'I pleH

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.17

Post by TheArkive » 07 Jul 2021, 09:56

Ok I'll try to answer these in the order of what appears to be most relevant :P

You might have a specific usage case that I had not anticipated, but I'm happy to check it out if it means making this script easier to use.

Before I get to the first part. Are your UAC settings active? Or disabled? I usually disable mine. I prefer to let my antivirus and firewall be the security for my system.

Next...

lmstearn wrote: If that refers to the main list at the top of the gui, it only ever shows as empty.

This is part of the fundamental setup. You need to click on this Settings button, then the Basics tab, first setting is Base AHK Folder. That needs to be set. Once that is set, then the listed subfolders (one AHK version per folder).

If you left it blank in order to point to the program folder, then I might need to do some more testing to make sure that kind of setup works as intended. I forgot that I put that in the settings :P

For now actually specify the folder and see if that populates the main list.

lmstearn wrote: Still haven't got much idea of how to switch back to v1 through the PI gui

This script is not usually meant to be used with legit installs. But that shouldn't throw any wrenches your way that ya can't work around. The best way is to download the AHK v1 version you want as a ZIP file from here. Yes, this link is legit, from autohotkey.com ;)

Unzip the contents of the ZIP file into a folder in your Base AHK Folder. By doing this, you let my script act as the "installer", instead of using the legit installer. If you go this route, then I suggest you actually uninstall your AHK v1 legit installation, and let my script handle all that. When in non-portable mode, clicking Activate EXE will actually write registry entries. The end result is the same as a normal AHK installation.

If this isn't an option, then you really need to use Fully Portable mode. As for getting your legit installation back up and running, the easiest way is to reinstall it.

Let me know what your situation is, regarding if you can let my script be the "installer" or not. Then we'll move on from there. There's a couple different ways this can go, so we'll stop here for now.

The main thing is to get that main list to populate. Nothing else will work if that doesn't happen.

User avatar
lmstearn
Posts: 688
Joined: 11 Aug 2016, 02:32
Contact:

Re: AHK Portable Installer v1.17

Post by lmstearn » 07 Jul 2021, 11:24

TheArkive wrote:
07 Jul 2021, 09:56
Before I get to the first part. Are your UAC settings active? Or disabled? I usually disable mine. I prefer to let my antivirus and firewall be the security for my system.
Yours is the better choice, they are enabled here, (not because it's desired but because for script testing, it is the default settings in most machines)
This is part of the fundamental setup. You need to click on this Settings button, then the Basics tab, first setting is Base AHK Folder. That needs to be set. Once that is set, then the listed subfolders (one AHK version per folder).

If you left it blank in order to point to the program folder, then I might need to do some more testing to make sure that kind of setup works as intended. I forgot that I put that in the settings :P

For now actually specify the folder and see if that populates the main list.
Cool, it's much better now, it was the "Leave blank for program directory" hint that caused the assumption it was referring to the A_AhkPath directory. The install mismatch warning hasn't gone yet.
This script is not usually meant to be used with legit installs. But that shouldn't throw any wrenches your way that ya can't work around. The best way is to download the AHK v1 version you want as a ZIP file from here. Yes, this link is legit, from autohotkey.com ;)

Unzip the contents of the ZIP file into a folder in your Base AHK Folder. By doing this, you let my script act as the "installer", instead of using the legit installer. If you go this route, then I suggest you actually uninstall your AHK v1 legit installation, and let my script handle all that. When in non-portable mode, clicking Activate EXE will actually write registry entries. The end result is the same as a normal AHK installation.
Okay, uninstalled it, and copied back in the 3 executables from the zip. Noted the Window Spy files are not replaced, but I think you have a solution for that.
Unfortunately, restarting PI and clicking Activate Exe gets:
-
Error: This value of type "String" has no property named "__Item".
--> 545: exeDir := ahkProps["exeDir"]
No difference with runas admin, and the version mismatch warning still persists.

Beginning to get it now- if Activate Exe is the opposite of Uninstall AHK, would De-Activate Exe be a better choice?
:arrow: itros "ylbbub eht tuO kaerB" a ni kcuts m'I pleH

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.17

Post by TheArkive » 07 Jul 2021, 11:49

lmstearn wrote: Yours is the better choice, they are enabled here...

That should only "slow things down", shouldn't actually be an issue as far as I remember. I will do more testing to try and ensure the reg entries are written when UAC is active and the user allows the action.

lmstearn wrote: ... the "Leave blank for program directory" hint that caused the assumption ...

Yah I need to rework that. Making it work properly by leaving it blank is certainly possible. A fix is under way.

lmstearn wrote: Noted the Window Spy files are not replaced...

The version of WindowSpy.ahk needs to match the version of AHK in that folder. So for AHK v1 ZIP files, keep the WindowSpy.ahk that is already there. I noticed you mentioned au3_spy.exe earlier. That isn't designed to work with this script at the moment. Only WindowSpy.ahk will work "with the script", but there shouldn't be anything preventing you from using au3_spy.exe as a standalone app (if it was designed that way).


There is no official WindowSpy.ahk for AHK v2 yet. But I linked to a version that I have converted in the docs on GitHub, and it is currently compatible with a138.

If you need intermediate versions of WindowSpy.ahk for earlier AHK v2 alphas, then you'll need to check the history on the GitHub repo.


In the meantime, you might want to try Fully Portable mode. The "activated" version is the one used to run scripts with a middle click.

Also, the "activated" exe is basically "installed". So, I'll rename that button to "Install" or "Choose" :P ... keeping it simple. "Uninstall" simply removes registry entries. In Fully Portable mode, it actually does nothing.

It is looking like FullyPortable mode might be your better bet. Try that, and let me know if you can run your scripts with middle click (don't forget to select first).

Thanks for the feedback. It will make this tool better :)

EDIT: Checking for updates does nothing when there are no updates compared to the last check. Would you prefer to see a confirmation for no updates?

EDIT2: Selecting "Run as Admin" is working fine on my end. Now that your main list is populating let me know if the Activate EXE button works.

EDIT3: On UAC some elements are likely to not work, unless you run certain scripts as admin. I may be able to add something to selectively run scripts as admin.

User avatar
lmstearn
Posts: 688
Joined: 11 Aug 2016, 02:32
Contact:

Re: AHK Portable Installer v1.17

Post by lmstearn » 08 Jul 2021, 05:34

TheArkive wrote:
07 Jul 2021, 11:49
The version of WindowSpy.ahk needs to match the version of AHK in that folder. So for AHK v1 ZIP files, keep the WindowSpy.ahk that is already there. I noticed you mentioned au3_spy.exe earlier. That isn't designed to work with this script at the moment. Only WindowSpy.ahk will work "with the script", but there shouldn't be anything preventing you from using au3_spy.exe as a standalone app (if it was designed that way).
There is no official WindowSpy.ahk for AHK v2 yet. But I linked to a version that I have converted in the docs on GitHub, and it is currently compatible with a138.
If you need intermediate versions of WindowSpy.ahk for earlier AHK v2 alphas, then you'll need to check the history on the GitHub repo.
Gotcha, and thanks. In fact, in my case, best not to obsess about Spy at all until it is officially released. :)
In the meantime, you might want to try Fully Portable mode. The "activated" version is the one used to run scripts with a middle click.
Also, the "activated" exe is basically "installed". So, I'll rename that button to "Install" or "Choose" :P ... keeping it simple. "Uninstall" simply removes registry entries. In Fully Portable mode, it actually does nothing. :(

It is looking like FullyPortable mode might be your better bet. Try that, and let me know if you can run your scripts with middle click (don't forget to select first).
Certainly makes a difference in the gui. The help works as well.
Hmmm, with the Logitech M185, the middle click on an AHK script brought up Window Spy for AHK V2! Yay. :D
However, subsequent clicks produce nothing. :(
Restarting PI or running elevated didn't help. How odd. Is there any chance of putting the items on the right-click menu? Or even CTRL- left click or something else?
Thanks for the feedback. It will make this tool better :)

EDIT: Checking for updates does nothing when there are no updates compared to the last check. Would you prefer to see a confirmation for no updates?
Glad to help. :)

Definitely! Notifications also help when a dingbat Activates Exe for a file in the list not selected yet. Nothing wrong with the msgbox going ding to tell us how something is the user end as well, missing files, restricted access, bad config or registry, and the rest!
EDIT2: Selecting "Run as Admin" is working fine on my end. Now that your main list is populating let me know if the Activate EXE button works.

EDIT3: On UAC some elements are likely to not work, unless you run certain scripts as admin. I may be able to add something to selectively run scripts as admin.
It's fine in the gui, somestimes UAC is required, sometimes not! Also unsure how to run the scripts in V2, though. Is it the same as in non Fully portable mode? Usually run scripts for N++ using the Run Me ShelL Execute. If there is a command for that, don't need the mouse click.

...

From a quote in this thread from last year:
Once all options are set as desired, then "activate" an EXE (basically activate = install). Doublel-click, or select and click the Activate EXE button.
Now restart. AHK should now be associated with .ahk extension.
Would using Reload be an alternative to a manual restart?
This might also be an idea after the selection of Fully Portable Mode.

Also, a thought, a multi-instance check of PI is better if only one instance is preferred.
:arrow: itros "ylbbub eht tuO kaerB" a ni kcuts m'I pleH

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.17

Post by TheArkive » 08 Jul 2021, 06:50

lmstearn wrote: Hmmm, with the Logitech M185, the middle click on an AHK script brought up Window Spy for AHK V2! Yay. :D
However, subsequent clicks produce nothing. :(
Restarting PI or running elevated didn't help. How odd. Is there any chance of putting the items on the right-click menu? Or even CTRL- left click or something else?

So..., in Fully Portable mode, you selected a script in an explorer window, or on the desktop, then middle-clicked, and it opened right?

Then replicating this process didn't work? That is odd, I'll have to try and replicate that. Please let me know if I got that right.

lmstearn wrote: Also unsure how to run the scripts in V2, though.

Check out the AHK Launcher tab in Settings. Delete all the versions in this list you won't use. Then double click on each of the remaining versions to select the proper EXE for the program to use. You will want to do this for all AHK v1 and AHK v2 entries in the list that you intend to use.

After this is done, insert this into the first line of your script(s): ; AHK v#, where # is the AHK version you want to use. This is the first line version comment. It is used to identify what EXE to use for launching the script, and relates directly to the AHK Launcher tab.

If you are using AHK 32-bit, then the first line version comment should be ; AHK v# 32-bit. This is according to the default regex match criteria I included with the script. You can change this to be whatever you like in the AHK Launcher tab. After making those changes, then change the first line version comment in your scripts so they can be properly identified, and then the proper EXE will be used to launch them.

If using non-portable mode, close the program for these settings to take effect.

lmstearn wrote: Would using Reload be an alternative to a manual restart?

The restart is only necessary in non-portable mode. After you check "Fully Portable" mode, there is no need to restart the script. The idea is that in non-portable mode, there is no need to keep this script running in the background. The settings the OS will use are written to disk on program exit. I suppose I could squeeze in a "Save" button, but this isn't really "more intuitive".

In non-portable mode, this script is an installer, and doesn't need to run in the background. So close it to save settings.

In Fully Portable mode, this script needs to run in the background, and no restarts are necessary; all settings take effect immediately.

lmstearn wrote: Also, a thought, a multi-instance check of PI is better if only one instance is preferred.

The #SingleInstance check is absolutely necessary in non-portable mode. If we get this working as intended, just try commenting out that directive, and then try running a script. You'll see why it's necessary, particularly when running a script with this program/script running at the same time.



I hope this isn't wearing you out, and thanks for the feedback, an update will be coming soon.

Now that the main list is populating, are you able to check non-portable mode? If you just use the context menu to run the script EXE as admin, then "activate" your chosen AHK v1 version from the main list and make sure your AHK v1 scripts work as intended. If this works, and if UAC works as expected then we are mostly done. Getting AHK v2 to work is then only a matter of configuring the AHK Launcher list in settings.

EDIT: What kinds of scripts do you guys normally run? There are known issues with running AHK when UAC is enabled. The one major advantage that a legit install of AHK offers is "Run with UI Access". I may be able to implement this, but it will take me a lot more time. At the moment I'm just working on a second line admin comment. In the update, if the 2nd line of a script is ; admin then the script will automatically be launched as elevated, but not with UI Access.

EDIT2:
lmstearn wrote: Usually run scripts for N++ using the Run Me ShelL Execute.

If you configure the AHK Launcher and add an appropriate first line version comment to your scripts as mentioned above, you can easily launch AHK v1 and v2 scripts the same way, side-by-side without the need to do any switching.

User avatar
lmstearn
Posts: 688
Joined: 11 Aug 2016, 02:32
Contact:

Re: AHK Portable Installer v1.17

Post by lmstearn » 08 Jul 2021, 10:00

TheArkive wrote:
08 Jul 2021, 06:50
So..., in Fully Portable mode, you selected a script in an explorer window, or on the desktop, then middle-clicked, and it opened right?
Then replicating this process didn't work? That is odd, I'll have to try and replicate that. Please let me know if I got that right.
The first time we middle clicked the file in desktop, nothing opened except Window Spy for v2. Then, nothing on middle click- in the explorer windows or anywhere else.
Edit: Problem this end- one has to hold the mouse down for a little longer than just a click. The script runs, and It works! The v2 scripts also run from N++, and Run from right click explorer menu. :)
Check out the AHK Launcher tab in Settings. Delete all the versions in this list you won't use. Then double click on each of the remaining versions to select the proper EXE for the program to use. You will want to do this for all AHK v1 and AHK v2 entries in the list that you intend to use.

After this is done, add ; AHK v#, where # is the AHK version you want to use. This is the first line version comment. It is used to identify what EXE to use for launching the script, and relates directly to the AHK Launcher tab.

If you are using AHK 32-bit, then the first line version comment should be ; AHK v# 32-bit. This is according to the default regex match criteria I included with the script. You can change this to be whatever you like in the AHK Launcher tab. After making those changes, then change the first line version comment in your scripts so they can be properly identified, and then the proper EXE will be used to launch them.

If using non-portable mode, close the program for these settings to take effect.
Interesting, scripts can now in v2 even without the first line version comment.
The restart is only necessary in non-portable mode. After you check "Fully Portable" mode, there is no need to restart the script. The idea is that in non-portable mode, there is no need to keep this script running in the background. The settings the OS will use are written to disk on program exit. I suppose I could squeeze in a "Save" button, but this isn't really "more intuitive".
In non-portable mode, this script is an installer, and doesn't need to run in the background. So close it to save settings.
In Fully Portable mode, this script needs to run in the background, and no restarts are necessary; all settings take effect immediately.
Ah, you have already given this some thought, so that's fine.
The #SingleInstance check is absolutely necessary in non-portable mode. If we get this working as intended, just try commenting out that directive, and then try running a script. You'll see why it's necessary, particularly when running a script with this program/script running at the same time.
That's fine, too- reason being accidentally starting one in FPM, the other was in non FPM- a bit of confusion, no major drama.
I hope this isn't wearing you out, and thanks for the feedback, an update will be coming soon.
Now that the main list is populating, are you able to check non-portable mode? If you just use the context menu to run the script EXE as admin, then "activate" your chosen AHK v1 version from the main list and make sure your AHK v1 scripts work as intended. If this works, and if UAC works as expected then we are mostly done. Getting AHK v2 to work is then only a matter of configuring the AHK Launcher list in settings.
Thanks, will check back on that tomorrow. :)
EDIT: What kinds of scripts do you guys normally run? There are known issues with running AHK when UAC is enabled. The one major advantage that a legit install of AHK offers is "Run with UI Access". I may be able to implement this, but it will take me a lot more time. At the moment I'm just working on a second line admin comment. In the update, if the 2nd line of a script is ; admin then the script will automatically be launched as elevated, but not with UI Access.
Sounds good. UI Access is for executables, so until we can officially compile with v2, not a worry at all.
Alternatively, add to PI an explorer treeview with a listview of favourite scripts, so we can configure and run all the scripts through the PI gui instead. Might take a bit of doing, though.
:arrow: itros "ylbbub eht tuO kaerB" a ni kcuts m'I pleH

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.17

Post by TheArkive » 08 Jul 2021, 10:25

@lmstearn
Just wanted to give you an update after some testing.

I had no issues with leaving the Base AHK Folder blank. I tried it straight from the GitHub repo. So I didn't change anything, and it still works ;)

I'm not sure what you did initially, but in general, if you put the AHK folders into the script dir, or in a subfolder in the script dir, then you can leave this setting blank. Otherwise, you must tell the script where to look for managing multiple versions of AHK.

Let me know if you still have issues with leaving that setting blank. Below is a screenshot of the script dir and where the AHK folders (for each version you intend to use) needs to go. Alternatively you can put these in a subfolder in the script dir and still leave that setting blank.


Image


So where do you stand on using AHK Portable Installer as an actual installer? If you have that option, then things will be much more convenient. Let me know if you want to continue testing this aspect.

I'll be releasing an update soon that will work better on systems that use User Account Control. The user must run this script as admin every time when making changes.

The user can optionally set "Run as Administrator" in compatibility settings (under file properties) for the EXE that runs this script in the script folder, but this will cause all scripts to be run as admin every time, though without UI Access. The updated script will be able to elevate launched scripts with a second line comment set to ; admin. Apparently AHK Portable Installer does not need elevated privileges to do this when using Run "*RunAs ..." discussed here in the AHK docs. Again, this still doesn't address UI Access.

I still have some Windows 7 testing to do on this area.

lmstearn wrote: Interesting, scripts can now in v2 even without the first line version comment.

If you select your main version as AHK v2 from the GUI, then no, you don't need a first line version comment to run v2 scripts. If you set the version selected to AHK v1, then you will need first line version comments in all your AHK v2 scripts. Make sense?

All scripts without a first line version comment will be run with the selected version in the main GUI.

The intent of this script is to actually set your selection once, and almost never change it. If you want to keep manually switching the active / installed version of AHK on the system, then yes you can do that as well, but you don't have to.

lmstrean wrote: The first time we middle clicked the file in desktop, nothing opened except Window Spy for v2.

It sounds like you had Win Spy for v2 (the .ahk script) on your desktop, and it was selected, then you pressed middle button. Ya have to select the file you want to run with left click (click once), and THEN middle click. It's an unfortunate side effect of trying to not kill the ability for the Windows Shell to launch all other file types with the normally expected double-click. It's theoretically possible for me to script my way around this. I might try, but it might also give weird results.

As for putting in some kind of script explorer in the man GUI, i might. The main focus for now is ease of use through the windows shell.

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.18

Post by TheArkive » 09 Jul 2021, 04:33

v1.18
  • Activate EXE button has been changed to Install Or Select, depending on if Fully Portable mode is enabled.
  • When the program is running, any files that do not have the .ahk extension will be ignored when using MButton hotkeys.
  • This script is now aware of User Account Control (UAC) settings. If UAC is enabled on your system, then use "Run as Administrator" to be able to install the .ahk file type extension. If this is not an option, then use Fully Portable mode.
  • To elevate a script automatically on launch, specify line 2 in your script as ; admin. UI Access is not currently implemented.
  • A few minor bug fixes.
  • Updated the docs on GitHub

User avatar
lmstearn
Posts: 688
Joined: 11 Aug 2016, 02:32
Contact:

Re: AHK Portable Installer v1.17

Post by lmstearn » 09 Jul 2021, 05:23

TheArkive wrote:
08 Jul 2021, 10:25
I'm not sure what you did initially, but in general, if you put the AHK folders into the script dir, or in a subfolder in the script dir, then you can leave this setting blank. Otherwise, you must tell the script where to look for managing multiple versions of AHK.

Let me know if you still have issues with leaving that setting blank. Below is a screenshot of the script dir and where the AHK folders (for each version you intend to use) needs to go. Alternatively you can put these in a subfolder in the script dir and still leave that setting blank.
So where do you stand on using AHK Portable Installer as an actual installer? If you have that option, then things will be much more convenient. Let me know if you want to continue testing this aspect.
FPM is surely an interesting and fun alternative, at this time the personal preference is to use PI in the default non FPM purely for use with v2.
Guessing that most folks starting to use PI have their AHK v1 files in the official v1 install directory. It is likely to be the path of least pain for them not to manually shunt files around overly, but to rely more on the file management facility of PI, once the milestone is attained. There may also be issues with PI interrogating the v1 executables in A_AhkPath which are not all that obvious, as a stopgap, folks wishing to switch from V1 <=> V2 need not have issue with PI copying files from the official install.
I'll be releasing an update soon that will work better on systems that use User Account Control. The user must run this script as admin every time when making changes.
The user can optionally set "Run as Administrator" in compatibility settings (under file properties) for the EXE that runs this script in the script folder, but this will cause all scripts to be run as admin every time, though without UI Access. The updated script will be able to elevate launched scripts with a second line comment set to ; admin. Apparently AHK Portable Installer does not need elevated privileges to do this when using Run "*RunAs ..." discussed here in the AHK docs. Again, this still doesn't address UI Access.
If you select your main version as AHK v2 from the GUI, then no, you don't need a first line version comment to run v2 scripts. If you set the version selected to AHK v1, then you will need first line version comments in all your AHK v2 scripts. Make sense?
All scripts without a first line version comment will be run with the selected version in the main GUI.
The intent of this script is to actually set your selection once, and almost never change it. If you want to keep manually switching the active / installed version of AHK on the system, then yes you can do that as well, but you don't have to.
Good info, thanks. Will be looking forward to the update. :thumbup:
It sounds like you had Win Spy for v2 (the .ahk script) on your desktop, and it was selected, then you pressed middle button. Ya have to select the file you want to run with left click (click once), and THEN middle click. It's an unfortunate side effect of trying to not kill the ability for the Windows Shell to launch all other file types with the normally expected double-click. It's theoretically possible for me to script my way around this. I might try, but it might also give weird results.
As for putting in some kind of script explorer in the man GUI, i might. The main focus for now is ease of use through the windows shell.
Might have been that. The middle click in explorer windows is fine, the desktop is a bit weird in that it deselects the item middle clicked, so has to be reselected on a rerun. All these quirks with the mouse, shell, along with some of the other info discussed above would look good in the docs as well. :)
Edit: Thanks for the update. :)
:arrow: itros "ylbbub eht tuO kaerB" a ni kcuts m'I pleH

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.18

Post by TheArkive » 09 Jul 2021, 05:48

lmstearn wrote: All these quirks with the mouse, shell, along with some of the other info discussed above would look good in the docs as well. :)

Agreed. That's why I specified selected (and now SELECTED) in the docs referring to how to use the MButton hotkey. Just curious, how would you change the docs to be more precise without being too long-winded?

lmstearn wrote: It is likely to be the path of least pain for them not to manually shunt files around overly, but to rely more on the file management facility of PI

Are you referring to having my Portable Installer download files and automatically unpack them to make things easier on the user? I'm up for considering that.

EDIT:

As for users trying to use this tool with a legit AHK v1 install, I already reference that in the docs, and my recommendation is to never do it. It's always better to use one or the other. And if the user wants to stop using AHK Portable Installer, then they can click the "Uninstall" button, and simply reinstall their chosen version of AHK.

Straight from the INTRO of the docs: This script is meant to work with the portable `.zip` archives of AutoHotkey, NOT the setup `.exe` versions.

Is this not clear enough?

lmstearn wrote: There may also be issues with PI interrogating the v1 executables in A_AhkPath which are not all that obvious.

Yes, I should probably add this in the docs, since many older versions of AHK v1 reference the registry for this (when compiled).

lmstearn wrote: folks wishing to switch from V1 <=> V2 need not have issue with PI copying files from the official install

Yes that should certainly work.

I'll be releasing another update soon, since "Run script as Admin" is currently titled as "Run Script" in the context menu. I will also update the docs regarding A_AhkPath.

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.18

Post by TheArkive » 09 Jul 2021, 06:19

@lmstearn
If you get a chance to test leaving the Base AHK Folder blank, with all AHK versions in the script dir (which can be in their own subfolder), that would be cool!

User avatar
lmstearn
Posts: 688
Joined: 11 Aug 2016, 02:32
Contact:

Re: AHK Portable Installer v1.18

Post by lmstearn » 09 Jul 2021, 09:00

TheArkive wrote:
09 Jul 2021, 05:48
Agreed. That's why I specified selected (and now SELECTED) in the docs referring to how to use the MButton hotkey. Just curious, how would you change the docs to be more precise without being too long-winded?
Just add an issues section at the bottom of the page- and raise any in the Github gui that have significant concern. List anything that can go wrong, annoyances, gripes or persistent bugaboos.
Are you referring to having my Portable Installer download files and automatically unpack them to make things easier on the user? I'm up for considering that.
Definitely, not forgetting the Window Spy and Help files. Consider clearing it with Lexikos & HotkeyIt in case there are issues.
Straight from the INTRO of the docs: This script is meant to work with the portable `.zip` archives of AutoHotkey, NOT the setup `.exe` versions.

Is this not clear enough?
Crystal. Include Bold or Bold Italic for extra eye catching effect.
If you get a chance to test leaving the Base AHK Folder blank, with all AHK versions in the script dir (which can be in their own subfolder), that would be cool!
It works, however switching from v1 to v2 (for example), PI (admin) must be restarted for the change to work.
In leaving the base blank, got an error in the AHK Launcher edit dialog on the folder button:
Set the Base Folder first.
Followed by a dead gui.
Btw, to avoid any confusion at all, it might be better to add PI in (Leave blank for program directory) to get (Leave blank for PI program directory)
Unable to provide further feedback at this time as other things have cropped up, will pop in at a later date to see how things are progressing. :wave:
:arrow: itros "ylbbub eht tuO kaerB" a ni kcuts m'I pleH

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.18

Post by TheArkive » 09 Jul 2021, 09:23

Very cool :D thanks for the feedback. Making some changes now.

@lexikos
Do you have any objection to my script parsing AHK download pages?

I am taking care to ensure that the web pages are queried as infrequently as possible. I'm also not allowing batch downloads. Just one at a time.

Basically, the only time the pages are queried is when the user does it, or when updates are available. And of course downloads only happen when the user specifies. Downloaded files are cached so repeat downloads won't be necessary, unless the user manually deletes the cache. I've tried to ensure the lightest usage possible of web resources.
Last edited by TheArkive on 09 Jul 2021, 15:44, edited 1 time in total.

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.18

Post by TheArkive » 09 Jul 2021, 10:01

lmstrean wrote: In leaving the base blank, got an error in the AHK Launcher edit dialog on the folder button:
Set the Base Folder first
Followed by a dead gui.
All these are fixed.

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

Re: AHK Portable Installer v1.18

Post by lexikos » 09 Jul 2021, 16:32

TheArkive wrote:
09 Jul 2021, 04:33
This script is now aware of User Account Control (UAC) settings. If UAC is enabled on your system, then use "Run as Administrator" to be able to install the .ahk file type extension.
Elevation is only required to write to register a file type for all users. You can register a file type for just the current user by writing to HKCU\Software\Classes instead of HKCR. As this is in HKCU, it should not require elevation.
Apparently AHK Portable Installer does not need elevated privileges to do this when using Run "*RunAs ..." discussed here in the AHK docs. Again, this still doesn't address UI Access.
Of course not. *RunAs is specifically meant for elevating. If you're already running as administrator, everything you Run runs as administrator regardless of whether you use *RunAs.

UI Access requires the program to be installed in a trusted location, such as the Program Files directory, on top of the manifest changes and a valid digital signature.

User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: AHK Portable Installer v1.18

Post by TheArkive » 09 Jul 2021, 16:40

lexikos wrote:
09 Jul 2021, 16:32
Elevation is only required to write to register a file type for all users. You can register a file type for just the current user by writing to HKCU\Software\Classes instead of HKCR. As this is in HKCU, it should not require elevation.
Thanks for the clarification. I normally run my system with UAC completely off, so lately I've been doing a lot more reading in the docs and experimenting to see how stuff works with UAC.

So about downloading. Do you have any requirements for downloading AHK zips direct through the script?

Edit:

I was looking at the installer and UI access stuff in v1. I might try to implement this somehow.

Post Reply

Return to “Scripts and Functions (v1)”