Upcoming Ahk2Exe Changes (2024)

Post your working scripts, libraries and tools for AHK v1.1 and older
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

15 Jun 2020, 06:25

Is there some reason for the addition of SetWorkingDir %A_ScriptDir% and removal of #Include %A_ScriptDir% in commit 33d35b91? This causes issues:
  1. Attempts and fails to #Include Compiler.ahk from the working directory instead of the Ahk2Exe directory.
    Spoiler
  2. Making all relative paths relative to the compiler directory instead of the caller's working directory. This breaks the AutoHotkey installer build script.
I was hesitant to just restore these lines in case Ahk2Exe uses relative paths internally for some purpose.

As you might've guessed, I am intending to release v1.1.33.00 shortly with the Ahk2Exe updates.
Last edited by lexikos on 15 Jun 2020, 16:33, edited 1 time in total.
Reason: Actually... #2 breaks the install script, #1 was just during testing.
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

15 Jun 2020, 08:32

From that merge, there is this commit for when it was changed. "Implement 'Cont' directive. Add 'exe_path\name parameter to 'Bin' directive"
https://github.com/TAC109/Ahk2ExeT/commit/e2173a40b608ff1a1326f8c95605dc88af4828cc

I believe it will be fine to change it back, but I guess I would be more confident knowing why from @TAC109.
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

15 Jun 2020, 16:00

@lexikos I'll check it out and get back to you.
There is also an issue that was reported yesterday on GitHub that I need to look at as well, but this should be easily fixed in a day or two.
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
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

15 Jun 2020, 23:55

Beta_9d 16 June 2020 -
  • Fixed 2 problems when compiling itself.
  • Fixed possible problem when running multiple compiles in parallel.
See this post for download details.
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
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 00:26

@lexikos
I believe I’ve fixed the two problems you found.
The #include is back in, and the original working directory is restored when Ahk2Exe exits.
I’ve also included a fix for the problem reported on GitHub.

So I believe we’re good to go.

I don’t know if you’d like to include into the installer the reg edit I included in beta's 9c and d?
It adds an entry to the compile context menu to allow the GUI to be shown.
Here’s the edit:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\AutoHotkeyScript\Shell\Compile (GUI)]
@="Compile Script (GUI)"

[HKEY_CLASSES_ROOT\AutoHotkeyScript\Shell\Compile (GUI)\Command]
@="\"C:\\Program Files\\AutoHotkey\\Compiler\\Ahk2Exe.exe\" /InGui \"%l\""

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: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 04:03

@TAC109
I think you misunderstand the problem. If I have the working directory (at the command line, in a batch script, or in any program) set to C:\A and I pass the path B\C.d, that should be interpreted as C:\A\B\C.d. Because of the added SetWorkingDir %A_ScriptDir% at startup, Ahk2Exe instead sees it as %A_ScriptDir%\B\C.d, which obviously won't work. I'll change the installer build script to pass absolute paths anyway, but I consider this new behaviour a bug.

Setting the working directory on exit will do nothing, as the working directory is per process. I suggest that the SetWorkingDir calls be removed completely. If Ahk2Exe actually uses relative paths to refer to files in the compiler directory (this is the part I wasn't sure of), I suggest these be changed to explicitly use %A_ScriptDir%.

It's not about Ahk2Exe compiling itself, but about Ahk2Exe.ahk compiling anything, and any relative path being specified on the command line for any purpose (with either Ahk2Exe.ahk or Ahk2Exe.exe).
I don’t know if you’d like to include into the installer the reg edit I included in beta's 9c and d?
Is it necessary to retain Compile Script (without GUI)? I don't like big context menus.

I just realized that Run doesn't support launching custom verbs with spaces. i.e. Run *Compile (GUI) "%A_ScriptFullPath%" (with any permutation of quotes) will not work, but if you omit the space from Run and the registry key, it will work. Of course, a script can run Ahk2Exe directly, but then it must include logic for finding the program, which kind of defeats the point of registering verbs.

I also just realized that if we add %* to the command line in the registry, a script can compile with parameters like this:

Code: Select all

Run *compile "%A_ScriptFullPath%" /compress 1
Why /in and /inGui? It seemed more natural to have /in (specify the input path) and /gui (just show the GUI). Now I realize that's also more flexible. With %* and /gui, a script could do this:

Code: Select all

Run *compile "%A_ScriptFullPath%" /gui /ahk "%A_AhkPath%"
It seems /inGui can't be used like that without repeating the script path, which would be silly.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 05:22

@lexikos
Relative paths for /in parameter: - ok, I’ll fix that tomorrow. (This has never been handled properly in a complete manner.)
Ahk2Exe has always used SetWorkingDir statements to handle #includes, so these cannot be removed.

Re reg entry:- just leave it if it is too much of a problem. Clearly I don’t understand the full ramifications of this. :(
In my simplified view I thought it would be useful if the user could have the additional option of being able to right-click a script and see the GUI with the script path filled in, so as to be able to change optional parameters for this compile.
This right-click option would be in addition to the existing 'compile script' option.
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
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 05:56

Couldn't the additional Compile (GUI) option be added as a submenu of the main Compile script, where first would be something like in background and second with GUI?
That would avoid the cluttering of the main context menu while offering the additional GUI option.
Also there would be no need for an additional .reg file as this would be handled by the AHK installer itself.
Part of my AHK work can be found here.
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 08:44

If the GUI option is to be added in the context menu, I do believe the submenu is the better option.
Also I do think /gui is less ambiguous and should be allowed to be used in combination with any of the other parameters. :+1:

In general, I don't think any program should be setting the working dir (unless somehow necessary and justified)... if relative paths are needed for some things, it should figure out the paths without setting working dir, no? :think:

@TAC109 Although I am still unsure as to why ahk2exe should be using SetWorkingDir, let me know if you need any help (or an extra "pair of hands") with any of these. :+1:
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 16:17

@joedf @lexikos @Drugwash
The general 'theme' of Ahk2Exe parameters is that of 'parameter pairs (/something something). This consideration led to my decision to implement the GUI option as part of the '/in' parameter (/in[gui]). It also make the documentation of the parameter pairs more straight forward and consistent in the help .chm.

As to how the .ahk context menu is organised, I have no strong feelings either way, except that I don’t think that two 'compile' options on the main menu is excessive. (The reg edit I posted was just an indication of what could be added to the installer.)
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: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 17:00

TAC109 wrote:
16 Jun 2020, 05:22
(This has never been handled properly in a complete manner.)
How so? I'm pretty sure it always resolved the parameters before changing the working directory, before. It wasn't done explicitly for some of the parameters, but that doesn't matter as long as it finds the right files.
Ahk2Exe has always used SetWorkingDir statements to handle #includes, so these cannot be removed.
That's fine; I only meant to refer to the more recently added calls.
Re reg entry:- just leave it if it is too much of a problem.
Did I make something out to be a big problem? I don't think I even mentioned any problems without also providing a simple solution.
This right-click option would be in addition to the existing 'compile script' option.
On first thought I didn't like the idea of an even longer context menu, so I suggested that the redundant "just compile immediately with default settings" item could be removed. On second thought I didn't really care about the extra length, and both compile options are useful (though rarely, for me).

Drugwash wrote:
16 Jun 2020, 05:56
Couldn't the additional Compile (GUI) option be added as a submenu of the main Compile script, where first would be something like in background and second with GUI?
That's one extra step and a slight delay, to click or hover over the menu to get at either option. May as well open the GUI and click Convert (and then close it). Actually, I suppose with the new directives there's less reason to go into the GUI each time, so I'll probably add both items directly.

Most of the clutter in my context menus is unrelated to the actual file type I'm clicking on. Those are the items that should be hidden away...

joedf wrote:
16 Jun 2020, 08:44
In general, I don't think any program should be setting the working dir (unless somehow necessary and justified)... if relative paths are needed for some things, it should figure out the paths without setting working dir, no? :think:
In general, command line utilities should (and mostly do) support passing relative paths, and therefore make use of whatever working directory the calling process gave (whether it was specified like with Run or just inherited). That includes GUI based utilities that accept a command line, like text editors. Programs that interpret relative paths on the command line as relative to their own directory exist, but are outliers; that behaviour is rarely useful or intuitive.

---
What does the GUI do if the /inGui file has directives overriding some of the parameters? Are the corresponding parts of the GUI still enabled and present, but ignored?
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 17:10

What does the GUI do if the /inGui file has directives overriding some of the parameters? Are the corresponding parts of the GUI still enabled and present, but ignored?
In short, yes.

Re relative file paths:- I’ll enable this for the /in[Gui] parameter today.
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
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 19:36

lexikos wrote:
16 Jun 2020, 17:00
In general, command line utilities should (and mostly do) support passing relative paths, and therefore make use of whatever working directory the calling process gave (whether it was specified like with Run or just inherited). That includes GUI based utilities that accept a command line, like text editors. Programs that interpret relative paths on the command line as relative to their own directory exist, but are outliers; that behaviour is rarely useful or intuitive.
+1
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 22:51

@lexikos etc
The parameters /in[gui], /out, /bin, and /icon will now accept relative paths.
Cheers

Edit: and /ahk.
Last edited by TAC109 on 17 Jun 2020, 02:06, edited 1 time in total.
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
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

16 Jun 2020, 23:59

awesome! :+1:
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

19 Jun 2020, 05:22

I took the liberty of replacing /inGui with /gui, so that I can release v1.1.33. I can't see any logical reason for /in and /gui to be combined.

While I was at it, I cleaned up the command line processing and fixed a couple of related bugs.


(Edit: The v1.1.33 release is being delayed by an issue with my latest code signing certificate.)
Last edited by lexikos on 19 Jun 2020, 06:14, edited 1 time in total.
Reason: update
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

19 Jun 2020, 08:53

Sounds good :+1:
Also, if funds (from donations) are needed for code signing, let me know.
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

22 Jun 2020, 18:15

Beta_9e 23 June 2020 -
  • Changed parameter /inGui to be two parameters; /gui /in.
  • Changed the included regedit file to reflect this.
  • Fixed an error when creating the default AutoHotkeySC.bin file for v2.0.
See this post for download details.
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
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

24 Jun 2020, 21:14

Beta_9f 25 June 2020 -
  • Fixed starting directory for #Include.
  • Implemented a more robust Unicode detection method.
See this post for download details.
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
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

10 Jul 2020, 00:49

This version is now included in the official AutoHotkey release (version 1.1.33.00). :D

Many thanks to everyone who contributed. :thumbup:
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

Return to “Scripts and Functions (v1)”

Who is online

Users browsing this forum: KnIfER and 87 guests