Upcoming Ahk2Exe Changes (2024)

Post your working scripts, libraries and tools for AHK v1.1 and older
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by joedf » 09 May 2021, 17:58

I like these new options, but I would opt to put the save and convert buttons next to each other and use tooltips for their descriptions instead.
An unvoiced complaint I've had with ahk2exe is the size of window, particularly the height. Perhaps we could even reduce the logo size a bit too.
An SVG of the logo is available here: https://www.autohotkey.com/static/ahk_logo_no_text.svg

Thoughts? :think:
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 (2021)

Post by TAC109 » 09 May 2021, 18:19

What is the basis of the 'unvoiced complaints'?

The current logo fits nicely with the text along side so I don’t see much point in reducing it.

I’d like to keep the save and convert buttons separate so that it is clear what they do without tool tips.

I could reduce the vertical spacing between lines.
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 (2021)

Post by joedf » 09 May 2021, 19:05

Sure sounds good, I think it's mostly when I was being lazy and needed to compile multiples things or doing compiled code specific things... so I needed to compile and test. I would keep Ahk2Exe always-on-top.

And now I don't think it makes much sense, since I should have used scripts and cli instead. So yeah :mrgreen:
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 (2021)

Post by TAC109 » 11 May 2021, 20:10

@lexikos
Are you planning on distributing.bin files with v1.1.34+ (and the corresponding v2)? If not, perhaps we could dispense with the Compiler directory and just have Ahk2exe.exe in the AutoHotkey directory. Then Ahk2Exe could check for no *.bin's in its directory and switch to the new mode for showing 'Base File' to use in the GUI. In the new mode it would just use the 'Base File' as the AutoHotkey.exe to use for those functions it needs performing.

The CLI /bin parameter should also be changed to /base.

What are your thoughts on the integration into Ahk2Exe?
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 (2021)

Post by lexikos » 11 May 2021, 23:11

I was thinking that v1.1 would continue to include bin files for compatibility, but v2 will not. The v2 download will not include v1 or Ahk2Exe (while it is based on a v1 binary), and that was what motivated me to make this change now.

The setup script (which could be used any time after installation) may offer download & install options for available AutoHotkey versions and a curated list of tools, including Ahk2Exe.

Ahk2Exe may be in the AutoHotkey root directory, while both old and new versions might be installed in subdirectories (but all managed within the one setup script).

To detect support for compiling with a given exe, you can check the version or maybe scan for a specific string (I assume the null terminated string "*#1" does not exist in old exe files).

With a multi-version setup, old versions might keep the same relative directory structure, but be installed/extracted to a subdirectory; e.g. C:\Program Files\AutoHotkey\v1.1.33\Compiler\Unicode 32-bit.bin. You probably don't need to pay attention to the folder names or locations if you just do a recursive file loop.

It might be ideal to select the version number first, then options within that version. (So maybe use the directory names in that case.)
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 12 May 2021, 05:34

TAC109 wrote:
09 May 2021, 17:13
In this version the defaults will be loaded and shown as before, but will only be saved when the save button is pressed. [...]
There will be a new optional /stop CLI parameter with bit settings for ExeName, SetMainIcon and Bin (4, 2, 1).
I think it is not intuitive for /bin to be ignored under any circumstance, and adding a switch that says "no, really, use the value I specified" is not a good answer.

The way I see it, ;@Ahk2Exe-Bin can specify a number of default builds, like having a script which calls the compiler with different /bin and /exe values (which is how I would have done it to begin with). This is useful for the context menu option, which specifies only the input file. But when I specify /bin on the command line, I clearly want to compile with that bin file. So there are only two valid responses:
  • Compile with that bin file only.
  • Compile with that bin file and the bin files specified by the directives.
Personally, I would expect the first one, and can't imagine any case where I would want some other behaviour while specifying /bin. The parameters are more immediately tied to the request, so should take precedence (as in: compile in file with bin and exe, and write to out). To put it another way, Ahk2Exe.exe is a function. When some of its parameters are omitted, they may take default values based on the input file.

If I want the compiler's default action to be taken as well, I'll call it again but without parameters. The compiler could support multiple sets of /bin /exe /out, and even something like /bin * to mean "each bin specified by directive", but it would be more straightforward to just run the compiler multiple times.


As for the GUI, it would be better to show precisely what values will be used based on the input file. This can be determined when the input file is selected, or when the file is modified (it would be sufficient to perform a check when the GUI is reactivated, as modifying the file would usually involve activating some other window).

The values could be read from the input file and used to populate the GUI. When the script is compiled, the values in the GUI should be used; i.e. the user may override the values defined in the script, by simply changing those values.

The directives have the flexibility to specify multiple sets of parameters, but the GUI does not. If you implement something like what Drugwash suggested, the GUI would be more flexible and would also have the capability to display what is actually going to happen when the user clicks Convert.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 12 May 2021, 23:10

@lexikos
You quoted the 'Save' button change but didn’t comment on it. Are you ok with this implementation?

I’ll drop the 'Stop' stuff as I agree it is rather clumsy.

There is the question of defaults, particularly with regard to the .bin file. At present an AutoHotkeySC.bin file is created in the compiler directory by the AutoHotkey installer. Will this continue? Will the v2 installer do this as well? At present Ahk2Exe likes to have this file and will create one if it is not present in the compiler directory.

I don’t see the necessity for the GUI to be able to compile many sources at once, other than from any bin directives in the source. The compiles go through quickly so it is just as easy to run a compile, change parameters then ‘compile' again. If this is needed often then the user can create a batch script to be run when required.

I can change the GUI to pre-process the source to find any bin directives but would rather just show 'Script Bin directives' in the drop-down for selection. If the user wants a variation they can select an overriding base file and any other required options in the GUI, which will cause Ahk2Exe to ignore the Bin directives.

I suggested earlier that the Compiler directory could be removed, but I think now that it is best to keep it. So the .bin files would be in the Compiler directory and the default .exe files in the parent directory. The /ahk parameter could be enhanced so that it can specify either a suitable AutoHotkey.exe or a directory containing suitable AutoHotkey executables, overriding the parent directory location. If the executable is version 1.1.34+ (or 2.0.??+) then it would be shown in the list of 'Base files' in the GUI.

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
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 13 May 2021, 04:52

TAC109 wrote: The /ahk parameter could be enhanced so that it can specify either a suitable AutoHotkey.exe or a directory containing suitable AutoHotkey executables, overriding the parent directory location.

+1
Just wanted to cast my vote. Hopefully it would scan that directory recursively, and omit any instance of Ahk2Exe.exe it finds.

(I'm under the impression Ahk2Exe is basically AutoHotkey.exe right? I'm not sure if this is even an issue.)

Of course it should be up to the user to select an "appropriate" exe to match the script syntax.

In some of my AHK version folders, there may be an AutoHotkey.exe which is a copy of AutoHotkeyU[32/64].exe. I would assume this would list some duplicates in the DropDownList to select a binary for compiling, which I think is ok. It should be the user's responsibility to clean up their archive of AHK versions to suit this new functionality in Ahk2Exe.



Just one question:

If these changes end up happening, is it likely that the BIN directive will change from requiring a .bin file, to either requiring, or also allowing, an .exe file?

Hope that makes sense. Let me know if I need to clarify anything.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 13 May 2021, 17:20

TheArkive wrote:
13 May 2021, 04:52

+1
Just wanted to cast my vote. Hopefully it would scan that directory recursively, and omit any instance of Ahk2Exe.exe it finds.
Yes

(I'm under the impression Ahk2Exe is basically AutoHotkey.exe right? I'm not sure if this is even an issue.)
Not really. Ahk2Exe is a compiled script. You may have seen this recent discussion on the meaning of some Ahk2Exe parameters.

If these changes end up happening, is it likely that the BIN directive will change from requiring a .bin file, to either requiring, or also allowing, an .exe file?
Yes

Hope that makes sense. Let me know if I need to clarify anything.
Will you still be using the folder structure you posted earlier?

Code: Select all

root\
    \Ahk2Exe
    \AutoHotkey v1.1.32
    \AutoHotkey v1.1.33
    \AutoHotkey v2-a120
    \AutoHotkey v2-a130
    \... and so on ...
I can code Ahk2Exe to scan these for appropriate 'base files', but will need some way of avoiding _H files as these are only compatible with the _H version of Ahk2Exe. (You’ll need to handle Ahk2Exe _H separately in some way as well.)
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
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 14 May 2021, 02:12

TAC109 wrote: Will you still be using the folder structure you posted earlier?

Yes.

I can have 2 subfolders, one for vanilla AHK and one for AHK_H, so then I would be able to direct vanilla Ahk2Exe to the appropriate folder.

So the structure would be relatively the same, but without AHK_H.

I'm excited for these changes :D
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 14 May 2021, 05:56

The 'Save' button is fine.
TAC109 wrote:
12 May 2021, 23:10
At present an AutoHotkeySC.bin file is created in the compiler directory by the AutoHotkey installer. Will this continue?
I was thinking that the v1 installer would behave as it has before. Users may have scripts set up to use files from the AutoHotkey directory.
Will the v2 installer do this as well?
Do what? There won't be any bin files to copy.
At present Ahk2Exe likes to have this file and will create one if it is not present in the compiler directory.
It will try to create one, and will show a warning if it fails. As far as I am concerned, there was never any reason for Ahk2Exe to do this. If Ahk2Exe can determine which file should be the default, it should use that directly, not make a copy. The user may be about to select a different bin anyway, or might have already selected a different bin and set it as the default.
The compiles go through quickly so it is just as easy to run a compile, change parameters then ‘compile' again.
Would the compilation taking longer make it harder? Compilation time didn't even cross my mind. If the user compiles a few exe files and then realizes something was missed, or tests the files and finds an error, he then needs to go through the process again, selecting each version and clicking Convert for each one.

Why set up a batch script to compile something that might not ever be compiled again? Most of my compiled scripts are solutions for specific problems, and don't get compiled more than once if they work.

I think a user who compiles multiple binaries for one script is likely to do it for other scripts. If the selection of multiple binaries could be saved as default, this saves him the trouble of setting up something (a batch file or Bin directives) for each new script.

Of course, the user can just write a (command line or GUI) script and use that instead of the Ahk2Exe GUI, or even write the compilation routine into the script being compiled.

This is mostly hypothetical for me, as I generally just use one of the Unicode bin files on the rare occasions that I compile. I can only recall compiling two scripts for public release. The most recent was AutoHotkey-jk, for which I used the Bin directives and then found I (of course) needed to specify /ahk, so I created a shortcut including the switch, but would have been better off creating a batch script from the beginning. The other script was WindowPad, which predates Unicode, x64 and Ahk2Exe.ahk.

By the way, I think ;@Ahk2Exe-ExeName would have more aptly been named OutputName or similar. On the command line we have /in .ahk, /out .exe... and /ahk .exe. Just looking in the documentation table of contents, "ExeName: Specifies the location and name for the .exe" is too vague. For Bin, "[Exe_path\][Name]" could easily be renamed to remove the ambiguity (between the output file and the exe used for auto-include/validation).
If this is needed often then the user can create a batch script to be run when required.
That seems like something I would have said if someone had suggested a directive be added for specifying parameters for compilation. The Bin directive is redundant, and unlike a batch script, can't be applied generally (other than by copy-paste) because the directives must be in the main file, not an #include. (I use the term "batch script" loosely, as it can be an ahk script, such as the script being compiled.)
I can change the GUI to pre-process the source to find any bin directives but would rather just show 'Script Bin directives' in the drop-down for selection. If the user wants a variation they can select an overriding base file and any other required options in the GUI, which will cause Ahk2Exe to ignore the Bin directives.
That's fine.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 14 May 2021, 06:08

TheArkive wrote:
13 May 2021, 04:52
I'm under the impression Ahk2Exe is basically AutoHotkey.exe right?
TAC109 wrote:
13 May 2021, 17:20
Not really. Ahk2Exe is a compiled script.
If you compile Ahk2Exe with one of the recent test builds (exe), then yes, Ahk2Exe is basically AutoHotkey.exe.

The bin files are also basically AutoHotkey.exe, but they lack /iLib and the ability to load external scripts.

I think the more relevant concern is how you identify which files to use. If you only want files that "are AutoHotkey.exe", you need some way to determine that programmatically. Of course, the standard AutoHotkey exe files can be identified by version information. Compiled scripts can be identified by the presence of a resource with name >AUTOHOTKEY SCRIPT< or ID 1 (and type RCDATA).

What is this for, again? Any compiled script can in fact be used to create another compiled script, by swapping out the resource; but you probably want to use only clean binary files. For a multi-version installation, my intention is for AutoHotkey.exe itself to be a compiled script (the launcher/version-selector). Despite it being a compiled script, there are two ways it could be used to validate a script prior to compilation:
  1. Run AutoHotkey.exe /iLib as normal, and it will execute its embedded script, which will execute some other exe with the same switches.
  2. Run AutoHotkey.exe /script /iLib tmpfile "scriptfile", and scriptfile will be processed directly by the (v2) interpreter in AutoHotkey.exe.

Version information - that reminds me: I assume Ahk2Exe only sets the version information if specified by directives. I think this should be changed for files based on an exe, to strip the standard AutoHotkey version information. Normally the bin files omit this information.
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 14 May 2021, 09:07

I'm a doof... I guess that wasn't helpful like i hoped.
Spoiler
Last edited by TheArkive on 15 May 2021, 09:13, edited 1 time in total.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 14 May 2021, 21:58

@lexikos
I’m finding your requirements for Ahk2Exe rather vague and not in line with the vision I had for this utility. Over the past few years, while I’ve been incorporating many of the enhancements previously requested for Ahk2Exe, you would have had plenty of time to suggest these changes and enhancements to the directives and GUI to suit your requirements, however they are coming to light just now.

The task of maintaining Ahk2Exe is becoming like an onerous unpaid job which I’m not enjoying right now (I retired from work many years ago). It is time for me to turn over the maintenance of Ahk2Exe to someone else whose thinking is more inline with yours.

All the best
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 (2021)

Post by lexikos » 17 May 2021, 04:59

@TAC109
From what I can recall of my recent participation in this topic, I have answered some questions, given my opinion bluntly and repeatedly, shared some ideas, made some complaints, and played devil's advocate. If you think my requirements are vague, perhaps that is because I haven't stated any. My expectation was that you would do what you want, which could be nothing, and if my requirement isn't met I would modify Ahk2Exe myself.

To be clear, my requirement is that Ahk2Exe continues to work after changes to AutoHotkey v2 and directory structure.

Your implication that I should have made suggestions over the past few years is confounding. Some of what I've suggested is only now becoming relevant. Some of it I'm only bringing up now because I'm actively involved in the topic, and I've been testing compilation repeatedly. Aside from recent testing, I've hardly used Ahk2Exe since before you started working on it; I've already said I don't compile often.

Why is it a problem that I'm bringing these things up now, all at once, instead of gradually over the past few years? There is no deadline to meet. This isn't a job. You're free to contribute as often or as little as you want, and you're free to disagree.

The task of maintaining Ahk2Exe is becoming like an onerous unpaid job which I’m not enjoying right now
I have had similar thoughts about AutoHotkey many times.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 18 May 2021, 19:00

@lexikos
To be clear, my requirement is that Ahk2Exe continues to work after changes to AutoHotkey v2 and directory structure.
Can you amplify the changes you’re contemplating? A complete example of the new directory structure would help as well.

You have published an AutoHotkey v1 test download to eventually be v1.1.34+. What v2 version will incorporate the new facilities for Ahk2Exe? What is a suitable method of differentiating new vs old v2 in this respect (with reference to version numbers, preferably). Also it would be helpful to know your future v2 version number strategy going to Beta and eventual final release.

With regard to other matters, I am prepared to carry on maintaining Ahk2Exe for now, but we’ll see how it goes.
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 (2021)

Post by lexikos » 19 May 2021, 03:59

v1.1.34.00 and v2.0-a135 will include the new facilities.

I intend to switch to semantic versioning post-alpha; i.e. v2.0-beta.1 ... v2.0.0.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 20 May 2021, 19:08

@TheArkive
You've retracted this post. Could you explain why, please?

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
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 21 May 2021, 02:20

@TAC109

I was trying to help with parsing version info. I was under the impression that "parsing the version info" was only parsing the string that looks like "v1.23.45.00". I've tried parsing that specific property with FIleGetVersion() and I have often been unable to tell the difference between AHK_H versions and normal AHK versions. So I tried to find a way to quickly and easily read the Product Name and Product Version.

As I was researching functions to manage resources, I realized that "parsing version information", as lexikos said, may be a far more complete concept than parsing just the file version. As I was going through the code in Ahk2Exe, it seemed that the functions to extract all the version info (including the Product Version, File Description, etc) already exist in the included libs.

EDIT: I'm still going over the code, just to learn, and possibly contribute. Just learning by trial and error. (and ms.docs) In particular, when I came across VerQueryValue in the source code (and learned what it does), I figured my initial assumption about "parsing version info" may have been wrong or incomplete.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 21 May 2021, 04:44

Thanks for your reply. Yes, AHKType.ahk in the source handles this. I’m enhancing this (or replacing some previously removed code) to also return FileDescription (as Description) to help check for AutoHotkey executables.

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
Post Reply

Return to “Scripts and Functions (v1)”