Test build - /include, compile with exe, ~custom combo fix

Community news and information about new or upcoming versions of AutoHotkey
Post Reply
lexikos
Posts: 7574
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Test build - /include, compile with exe, ~custom combo fix

Post by lexikos » 11 May 2021, 17:21

This test build includes:

  • A new command line switch /include path, includes a single file (or a named pipe or stdin, as usual) before the main script. Only one is supported. It is retained when reloading the script. When executing a compiled script without the /script switch, /include is not interpreted (it is passed to the compiled script). It might have uses such as:
    • Including common settings or modified functionality for all scripts executed on a system (by adding /include into the registry).
    • Integrating editors and other tools, such as enabling #Warn All, StdOut or hooking runtime errors with OnError.
  • The ability to compile a script based directly on an exe, and use it to execute external scripts. Details as in this post, with the following changes:
    • /execute has been renamed to /script.
    • If present, RCDATA resource ID 2 is automatically #included before every script the exe loads, regardless of whether resource ID 1 is present. This can be used for purposes similar to /include, but embedded in the exe file itself.
  • A fix for the behaviour of the tilde (~) prefix when applied to the prefix key in context-sensitive custom combinations. Details here.

AutoHotkey_1.1.34-TEST+ge02b563d.zip

User avatar
TheArkive
Posts: 606
Joined: 05 Aug 2016, 08:06
GitHub: TheArkive

Re: Test build - /include, compile with exe, ~custom combo fix

Post by TheArkive » 15 May 2021, 08:16

I've looked into enumerating and updating resources and I understand the general concept. If one were to embed the RCDATA resource type into any other AHK exe version other than this test version, (of course assuming the old name of >AUTOHOTKEY SCRIPT<), is it correct to assume those older exe's are not designed to execute that resource?

Is that by chance one of the the main purposes of the .bin files? To be able to look for an embedded script and execute it?

I'm trying to picture in my head the over-arching order of operations. I'm looking into Ahk2Exe code now to try and learn. Like drinking from a fire hose... (still fun though).

I'm aware the answer is likely more complex than my questions imply, I'm just trying to wrap my head around the main concepts so I can figure out how to properly connect the dots in my head.

lexikos
Posts: 7574
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Test build - /include, compile with exe, ~custom combo fix

Post by lexikos » 16 May 2021, 23:03

Correct.

The bin files omit other things that aren't needed for compiled scripts, like #include and some load time validation. The previous exe files omitted some things only used by compiled scripts, like code for reading a stream of text from memory instead of a file, and the implementation of Menu Tray, MainWindow.

The new exe files use resource ID 1, as I noted in the Ahk2Exe topic.

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

Re: Test build - /include, compile with exe, ~custom combo fix

Post by TAC109 » 08 Jul 2021, 22:22

@lexikos
I’ve been using this test version of AutoHotkey in my testing of Ahk2Exe and have found that when an AutoHotkey exe is used with the /ilib parameter and there are no auto-included files for the script, AutoHotkey still outputs a file containing only a UTF8 BOM (EF BB BF). In previous versions, no file was created in this situation. Could you take a look at this, please.

Also, I take it that when Ahk2Exe is processing #Include directives it should just pass through unchanged any with file names that start with '*' as these should be processed by the embedded interpreter at load time (looking at 'Embedded Scripts' in the help).

(A cool feature of the new facilities in 1.1.34 is that if the user wants to only create v1 u32 .exe's, Ahk2Exe can be used completely stand-alone to do this, using itself both as the base file, and for any /ilib and 'Obey' directive processing! :) )

Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility

lexikos
Posts: 7574
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Test build - /include, compile with exe, ~custom combo fix

Post by lexikos » 09 Jul 2021, 04:52

TAC109 wrote:
08 Jul 2021, 22:22
In previous versions, no file was created in this situation.
I have confirmed that is not true; a file with only a UTF-8 BOM is created in both v1.1.33.09 and revision 42 (the first release with Unicode support). The iLib output file is opened during processing of the command line switches. The file is created as a side-effect of "opening" it, and AutoHotkey then immediately writes a UTF-8 BOM if the file has zero length. Before Unicode support was added, a zero-byte file was created.

It behaves the same as FileOpen(filename, "w", "UTF-8") (and uses most of the same code).
Also, I take it that when Ahk2Exe is processing #Include directives it should just pass through unchanged any with file names that start with '*'
That sounds right.

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

Re: Test build - /include, compile with exe, ~custom combo fix

Post by TAC109 » 09 Jul 2021, 20:50

lexikos wrote:
09 Jul 2021, 04:52
TAC109 wrote:
08 Jul 2021, 22:22
In previous versions, no file was created in this situation.
I have confirmed that is not true; a file with only a UTF-8 BOM is created in both v1.1.33.09 and revision 42 (the first release with Unicode support). The iLib output file is opened during processing of the command line switches. The file is created as a side-effect of "opening" it, and AutoHotkey then immediately writes a UTF-8 BOM if the file has zero length. Before Unicode support was added, a zero-byte file was created.
Ah, a long-standing bug. :D
I’ll program around it.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility

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

Re: Test build - /include, compile with exe, ~custom combo fix

Post by TAC109 » 12 Jul 2021, 00:02

I've encountered a problem when trying to pass parameters to a compiled script, in that parameters passed to that compiled script are not recognised at all. This may be demonstrated by first compiling a suitable v1.1.34 Ah2Exe (edit: with the U32.exe base file) and then using it to compile this test script.

Code: Select all

#NoEnv

Loop %0%
  O .= %A_Index% " "
for k, v in A_Args
  p .= v " "
MsgBox %o%`n%P%
When running the generated test.exe from the command prompt with parameters, none are shown.

Edit: Actually you can probably skip the 'generating Ahk2Exe.exe' step and just compile the test script with Ahk2Exe.ahk using the v1.1.34 base file. (I did the main post in a rush.)
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility

lexikos
Posts: 7574
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Test build - /include, compile with exe, ~custom combo fix

Post by lexikos » 16 Jul 2021, 18:32

TAC109 wrote:
12 Jul 2021, 00:02
When running the generated test.exe from the command prompt with parameters, none are shown.
I've updated the top post with a fix for this issue.

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

Re: Test build - /include, compile with exe, ~custom combo fix

Post by TAC109 » 22 Jul 2021, 20:11

lexikos wrote:
09 Jul 2021, 04:52
Also, I take it that when Ahk2Exe is processing #Include directives it should just pass through unchanged any with file names that start with '*'
That sounds right.
I've been further testing Ahk2Exe, and although Ahk2Exe itself now allows #Include *... to be passed through into the compiled script, it is rejected when Ahk2Exe calls the appropriate v1.1.34 AutoHotkey /ilib ... during the compile. So as it stands now, #Include *... can only be used in non-compiled scripts. Any further thoughts?
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility

lexikos
Posts: 7574
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Test build - /include, compile with exe, ~custom combo fix

Post by lexikos » 23 Jul 2021, 03:08

The standard way to allow a failed #include to be ignored is to add the *i prefix. This should work in combination with a *resource, as in #include *i *resname.

I suppose /iLib could ignore any failed #include *resource. However, the content of the resource may affect how the remainder of the script is processed - e.g. functions that are supposed to be defined in the resource being auto-included from file instead, or warnings/errors due to missing definitions.

If you are compiling a script with #include *resource, the resource is a dependency of the script, and compiling without it simply may not work. I suppose the correct way would be to create the executable with the resource first, and use that for /iLib.

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

Re: Test build - /include, compile with exe, ~custom combo fix

Post by TAC109 » 23 Jul 2021, 04:49

I personally can’t see that '#include *resource' is useful in a compiled script in that it doesn’t seem to offer the script writer anything extra over a standard #Include. Unless you can see some advantage in allowing this I suggest that we leave it as is.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility

lexikos
Posts: 7574
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Test build - /include, compile with exe, ~custom combo fix

Post by lexikos » 23 Jul 2021, 19:01

#Include *resource exists purely as a side-effect of the method used to support both resources and files in one build. Although I knowingly designed it in a way that would support command line use and #include, #include *resource wasn't a particular priority and (iirc) there is no code specific to it.

Anyway, I'm not sure that my last paragraph came across clearly. If #include *resource is used in a script, the resource presumably must exist in the base executable file. If the resource exists in the file used with /iLib, it should already work. Otherwise, I suppose you are using the wrong executable file with /iLib, or the wrong resource name (which should be reported as an error).

Resource directives in the script might be intended to add those resources, in which case I suppose the resource directives would have to be processed before the #include (and maybe it would already work if written in the correct order; I don't know). But that use isn't what I had in mind. I was thinking along the lines of a program built with AutoHotkey, where *#1 contains the main program logic and *resources contain sub-programs or libraries for use with scripts that extend the program. I suppose the program itself can already be built with Ahk2Exe, although maybe one would want each *resource to be preprocessed by Ahk2Exe (is there a command line switch to specify the target resource name yet?).

In any case, I wasn't concerned about Ahk2Exe supporting it at this point. If and when someone comes up with a use for it, not having direct support for some small part of it in Ahk2Exe isn't a show-stopper. One can either modify Ahk2Exe or work around it (as I did while testing this).

Post Reply

Return to “Announcements”