AutoHotkey Community

It's logical for all running variants to be identical in capabilities. One may have a multitude of scripts to compile - some using Directives, others not. And then even when using Directives there may be something wrong that would be much easier to fix in the GUI than searching, editing, saving, especially when one is in a hurry.

Also, one may launch the tool in CLI mode from a shortcut, a batch file or whatever means other than having the actual AHK script at hand; in this case the /forcegui parameter may come in handy if one forgot what parameters are being used for that particular script.

So my opinion is that the GUI should always take precedence and should contain all possible elements that can be tweaked through Directives or CLI. And that would require some careful refactoring, in order to help but not confuse the user, be them novice or expert.

Anyway, this is not an emergency or anything, and I got enough on my plate with all 17 kittens in the house, so can't promise any concept UI soon. Anyone else could try their hand though.

We are going to freeze development of the master branch at Beta 9 so that all the changes to date can be included in the next release of AutoHotkey 1.1. Any future proposed amendments should be created in a new branch.

@lexikos I have also completed amendments to the documentation in github.com/TAC109/AutoHotkey_L-Docs master branch. Do you want them pushed?

Hi TAC,
A quick note to let you know that I ran the same set of tests documented in a previous post with Beta_9 on both 1.1.31.01 and 1.1.32.00 — everything worked perfectly! And thanks for changing MPress to MPRESS. Regards, Joe

@JoeWinograd
Thanks for testing

@lexikos
If you can give me an expected release of AutoHotkey for Ahk2Exe inclusion, I can amend the version number in the documentation.

v1.1.33.00, although I currently have nothing else planned for that release. When the documentation is ready for release, submit a pull request - this improves the odds that I won't forget about it.

@lexikos oh well

Updated help file 30 January 2020 -

• The Compiler Directives information has been merged into the latest AutoHotkey version 1.1.32.00 help.

See this post for download details.

Note that the Beta_9 posted on 20 November 2019 is still the latest version of Ahk2exe.

TAC109 wrote:The Compiler Directives information has been merged into the latest AutoHotkey version 1.1.32.00 help.

Nice!

Thanks!
Now you can copy the .chm to your installation folder and just use the one help file.
Cheers

Yep! Did that as soon as I saw your post.

I can't wait to see this fully included in the next release.
I hope that's soon. Lexikos has been AWOL since early December 2019

Does Ahk2Exe need AutoHotkey.exe at all?

Is there a difference between having 32/64-bit AutoHotkey.exe being registered in the registry and selecting the 32/64-bit .bin file in whatever combination?

I'm just trying to understand the finer aspects of how Ahk2Exe works. I'm making a portable installer and this is one aspect I'm not sure on.

Specifically: Is Ahk2Exe completely standalone? Or does it require AutoHotkey.exe to be registered in the registry? Or something?

Yes, AutoHotkey.exe is required by Ahk2Exe, and is looked for (in the normal case) in the folder immediately above the folder containing the compiler. So if you preserve the downloaded .zip directory structure you should be fine.

As you know, in the AutoHotkey folder, one of the downloaded AutoHotkey exe's should be copied to make 'AutoHotkey.exe'. In the same way, in the Compiler folder one of the .bin files should also be copied to make the 'AutoHotkeySC.bin' file (usually the one corresponding to the 'AutoHotkey.exe' in the folder above). 'AutoHotkeySC.bin' becomes the default .bin file to be used by Ahk2Exe, although the user can select one of the other .bin files if required.

Hopefully this answers your questions

@TAC109 yah that's good info. Thanks! Just one a few more question(s).

What's the difference of having 32-bit AHK exe active, and selecting the 64-bit .bin ... or having 64-bit AHK exe active and selecting the 32-bit .bin ???

I imagine a true 64-bit compile isn't possible with 32-bit AHK exe, but is there a difference in 32-bit compilation between the 32/64-bit exe's?

EDIT: I guess this question is the same as the one above but worded differently...
Is it recommended to use matching AHK exe and .bin? Is using 64-bit AHK and 32-bit .bin considered the same as 32-bit AHK and 32-bit .bin?

There is no correlation necessary between the bit-ness (or ANSI/Unicode-ness) of AutoHotkey.exe and the .bin file used for Ahk2Exe compilation. Any can be used for any (if that makes sense). In fact the minor version of AutoHotkey could be different from the version of the .bin files (although this is not particularly recommended!)

However, the major versions must be the same, so if compiling with a version 2 .bin AutoHotkey must be version 2.

Background notes:

AutoHotkey.exe is called by Ahk2Exe to find 'implied #includes' in the script (called 'library functions' in the documentation) and returns a list of these to Ahk2Exe for inclusion into the generated .exe. So it is only necessary for AutoHotkey to understand the script enough to generate this list, and all Unicode/ANSI versions can do this.

In addition the beta version of Ahk2Exe (referenced in this thread) also uses AutoHotkey.exe to execute any 'Obey'-type Compiler Directives. So, as long as the version of AutoHotkey being used understands the command being 'obey'ed, all is good.

Hi TAC,
I hope you are doing well and staying safe.

Beta9 has been working great for the past few months...I use it for all my compiles. But for the first time I just compiled a script with a FileInstall in it and the EXE failed to run...displayed a dialog that says, "Could not extract script from EXE." To make sure that Beta9 was the problem, I compiled it with the released 1.1.32.00 Ahk2Exe, and the EXE ran fine, so it definitely seems that the issue is with Beta9. Can you reproduce the problem there? Regards, Joe

Edit: Meant to say that my FileInstall command uses an absolute path, so the problem is not the bug that was in the old version where a relative path in FileInstall was not parsed correctly.

@JoeWinograd Thanks for the report. I’ll check it out.

All well here. About half way through our lockdown!
Take care

Glad to hear you're doing well and staying safe. Read a Washington Post article entitled, "New Zealand isn’t just flattening the curve. It’s squashing it." Very impressive!

Thanks for looking into the FileInstall issue. Regards, Joe

@JoeWinograd
FileInstall works for me...

Could you check any ;@Ahk2Exe-PostExec "BinMod.exe" lines please? The error message could occur if the >AUTOHOTKEY SCRIPT< replacement field is not space-filled to exactly 19 characters long.

Otherwise, use ResourceHacker with the .exe and check RCData. It should show the FileInstall file name(s) in upper case as well as the script name (default >AUTOHOTKEY SCRIPT<).

Cheers

> FileInstall works for me...

Good to hear.

> Could you check any ;@Ahk2Exe-PostExec "BinMod.exe" lines please? The error message could occur if the >AUTOHOTKEY SCRIPT< replacement field is not space-filled to exactly 19 characters long.

I haven't changed the replacement string since I first started using it a couple of months ago. It is 19 chars, all upper case.

> Otherwise, use ResourceHacker with the .exe and check RCData. It should show the FileInstall file name(s) in upper case as well as the script name (default >AUTOHOTKEY SCRIPT<).

ResourceHacker shows that RCData has the replacement string (19 upper case chars) followed by four FileInstall files. All four FileInstall files have correct names, with the full path and all upper case. If it matters, the four files are an ICO, INI, TXT, PDF, in that order. The problem occurs both with and without MPRESS. If I comment out the four FileInstall commands, it compiles and runs fine. Regards, Joe

Edit: Btw, without MPRESS, ResourceHacker shows the script, the INI file, and the TXT file perfectly.