Syntax for AHK V2 documentation not valid according to compiler Topic is solved

[JamesR404]

Hi guys,

I've got plenty of problems trying to make a script work. And at this stage need your help and eye balls to point out whatever I'm doing wrong.

I wanted to use some functionality only available in AHK V2.

I'm tearing my hair out, as as far as my eyes can tell, the syntax is exactly the same as in the AHK V2 documentation, but if I try to compile the script it says that the script contains errors:


1) WinGetCont

Error: The script contains syntax errors.

Specifically:
C:\Dropbox\GTD portable\MindMap\dualmindmapper.ahk (74) : ==> Call to nonexistent function.

Specifically: WinGetCount("WorkFlowy")

But the documentation here:
https lexikos.github.io /v2/docs/commands/WinGetCount.htm Broken Link for safety
says:
Count := WinGetCount(WinTitle, WinText, ExcludeTitle, ExcludeText)

and I wrote:
WINDOWZ := WinGetCount("WorkFlowy")

2) SendMode Input

C:\Dropbox\GTD portable\MindMap\dualmindmapper.ahk (13) : ==> Call to nonexistent function.
Specifically: SendMode("Input")

but the doc https lexikos.github.io /v2/docs/commands/SendMode.htm Broken Link for safety says:
SendMode "Input"

And I wrote
SendMode "Input"


3) SetTitleMatchMode("RegEx") or SetTitleMatchMode RegEx
C:\Dropbox\GTD portable\MindMap\dualmindmapper.ahk (141) : ==> Parameter #1 invalid.
Specifically: "RegEx"

The documentation https lexikos.github.io /v2/docs/commands/SetTitleMatchMode.htm Broken Link for safety says:
SetTitleMatchMode "RegEx"

I wrote
SetTitleMatchMode "RegEx"


If you want the whole source code, here it is: https www.dropbox.com /s/ypbx7148uo2kowt/dualmindmapper.ahk?dl=0 Broken Link for safety

Please, I would seriously appreciate ya'lls help.

[JoeWinograd]

Hi James,
My guess is that you're running the script with AHK V1, not V2. Regards, Joe

[TAC109]

@JamesR404
You need to copy the Ahk2Exe.exe from latest v1.1.33.02 download to the v2 Compiler directory and run it from there. It will then make use of the v2 AutoHotkey file(s) in the directory above the Compiler directory, as needed.

So the file structure should be:

Code: Select all

 AutoHotkey directory (v2)
   | (AutoHotkey*.exe files from the v2 .zip)
    \
     Compiler directory
       Ahk2Exe.exe (copied from v1)
       (*.bin files from the v2 .zip)

Cheers

[JamesR404]

@TAC109 Thanks for that advise. I guess you are right and the compiler is using v1.1 bin files to compile.

If I follow the steps you advised, I still get the same errors.

Then I tried running ahk2exe (beta 9f) from a subfolder in the AHK v2 directory, without any bin files in the directory, and I notice it copies the V1.1 bin files and shows those in the dropdown list. Why is it copying V1.1 files whereas there are V2 files in the parent directory?!

I don't understand where it gets those from?! The v1.1 files are not in the parent directory. So is it using the windows registry or some environment variable?

Anyway, in the end, it doesn't seem to matter which bin I am using. v2.0 or v1.1, it all behaves as if it is v1.1 - so maybe somehow in the background something is causing it to stick to v1.1?

If I click on "Convert" in either of these two examples (https www.dropbox.com /s/rw5u5antynk5g9u/bin%20choices.png?dl=0) Broken Link for safety I will get the same compile errors, which find any V2 syntax offensive

I appreciate further guidance. Also a link to the correct ahk2exe to use may be useful, I only now discovered in my dropbox I have multiple versions of ahk2exe because the file size differs. So I took that beta 9 version from https://github.com/AutoHotkey/Ahk2Exe but I am not sure if that's the latest one

[Tigerlily]

@JamesR404

The solution to your issue is pretty simple, I've ran into it myself:

1. Download the latest V2 .zip file from the AutoHotkey Homepage and unzip it.
https://www.autohotkey.com/download/2.0/AutoHotkey_2.0-a122-f595abc2.zip

2. Copy the Ahk2Exe.exe found in
Program Files > AutoHotkey > Compiler
into that folder you unzipped
(e.g. AutoHotkey_2.0-a122-f595abc2 > Compiler)

3. Run Ahk2Exe.exe now located in the unzippd folder (it will now use the .bin files found in that folder to compiled into a V2 script. You will know because you will see this:


P.S. There is no "correct version" of Ahk2Exe.exe except the latest released version (I don't know where you are finding beta 9f). To get a fresh copy, I download the latest V1 release as an installer.exe file (https://www.autohotkey.com/download/ahk-install.exe), Install AHK V1 into my Program Files directory (default location). Then can find Ahk2Exe.exe at Program Files > AutoHotkey > Compiler which is probably where yours is located too. An easier method is to just download the latest V2 .zip file (https://www.autohotkey.com/download/ahk.zip) and pull the Ahk2Exe.exe file from that into the newly unzipped v2 Compiler folder.

Cheers.

[JoeWinograd]

Hi TAC,
I'm convinced there's a bug. Here are my V2 root folder and Compiler subfolder:

v2 root.png (16.39 KiB) Viewed 4858 times

v2 compiler.png (18.86 KiB) Viewed 4858 times

Here's a test script that shows the bug:

Code: Select all

fileCurrentVersion:=A_Temp . "\AutoHotkeyCurrentVersion.txt"
urlCurrentVersion:="https://autohotkey.com/download/2.0/version.txt"
Download(urlCurrentVersion,fileCurrentVersion)
MsgBox("Debugging")
ExitApp

Running that script from source code works fine. But after compiling it by running Ahk2Exe.exe in the V2 Compiler subfolder shown above, running the compiled EXE gives this:

v2 compile bug.png (8.99 KiB) Viewed 4858 times

That happens when selecting both 32-bit and 64-bit in the Base File (.bin) drop-down. Regards, Joe

[TAC109]

@JoeWinograd
@JamesR404
Yes, there is a bug! If there is an installed version 1.1 of AutoHotkey and there is not an AutoHotkey.exe in the v2 folder (copied from one of the downloaded v2 AutoHotkeyU32.exe or AutoHotkeyU64.exe files) Ahk2Exe will mistakenly use the installed v1 for its processing.

The circumvention is to copy AutoHotkeyU32.exe (or *U64.exe) renamed to AutoHotkey.exe in the same v2 folder. I’ll fix this in Ahk2Exe and publish the fixed version in this thread.

Cheers

[JoeWinograd]

The circumvention is to copy AutoHotkeyU32.exe (or *U64.exe) renamed to AutoHotkey.exe in the same v2 folder.

Brilliant! Tested with both AutoHotkeyU32.exe and AutoHotkeyU64.exe...works a charm! Thanks for the fast work-around and thanks in advance for the fix in the published version. Regards, Joe

[TAC109]

I've posted a new release of Ahk2Exe here which fixes this problem. (This version also contains other fixes and enhancements).

@JamesR404
I believe your other problem can be cured by following these steps:

• Unblock the downloaded V2 .zip by right-clicking it, selecting 'Properties', ticking/pressing 'Unblock', and 'OK'ing out.
• Unpack the downloaded version of V2, preserving the .zip folder structure. (Do not move or delete any files.)
• Copy Ahk2Exe.exe (obtained from the above link, unblocked) into the Compiler\directory created in the previous step.
• Run Ahk2Exe.exe from the Compiler\ folder.

Cheers

[JoeWinograd]

I've posted a new release of Ahk2Exe here which fixes this problem.

Hi TAC,
Just a quick note to let you know that I tested the new release of Ahk2Exe...worked perfectly in fixing the problem! I had a vanilla folder structure of the current V2 (2.0-a122-f595abc2 U64) and copied the new Ahk2Exe.exe into the Compiler subfolder. Also copied it into the Compiler subfolder of the current V1 (1.1.33.02 U64). Then compiled with both V1 and V2, and both 32-bit and 64-bit. All four compiled without errors and the EXE files ran fine. Great job! Thanks for the quick fix. Regards, Joe

[TAC109]

Joe, thanks for your confirmation!

[JamesR404]

Hey! That's truly amazing to me!

Thanks for confirming the bug and explaining it so well @JoeWinograd , and coming up with the workaround.

Thanks @TAC109 for fixing it so super quickly!

[TAC109]

@JamesR404
You’re welcome!

[JoeWinograd]

Thanks for confirming the bug and explaining it so well @JoeWinograd , and coming up with the workaround.

You're welcome, James, but to be clear...and give credit where credit is due...it is TAC109 who came up with the work-around...all I did was test it. Regards, Joe