AutoHotkey Community

I tend to be slow with adopting new versions of AutoHotKey, but recently I have decided to upgrade (from 1.0.27 to 1.0.40.08). My fears were confirmed when my scripts stopped working. It seems that I am unable to create global variables now. Can anyone help me?

An excerpt from WGET.AHK (I kept everything that's outside of functions, but removed all functions, because they are unnecessary):



For some strange reason, the message box displays "var = ". This same construct worked fine in the older versions.

I tested your code, it works on my machine.
AHK 1.0.40.08
WinXP Pro SP2

_________________
Ciao
toralf

Interesting. It seems to work if I run it alone (autohotkey.exe wget.ahk). It even runs if I include it in another script, if I only keep a simple Include in that script. But it won't work in my normal setup. I'll try to locate what causes the problem.

Very interesting. This script works:



But this script does not:



The first part minimizes Jetico Personal Firewall window when the script is first run.

It's even more interesting if I move the Jetico section AFTER the variables are defined - the script works once again.



Am I missing something or is it a bug in AutoHotKey?

because your second code wait indefinitely with WinWait if the Window doesn't exist. Try the code with 1 second as timeout on the winwait. Let's see if that's the problem.

_________________
Ciao
toralf

More tests, more confusing results. Far.ahk always contains this:



My main script pepak.ahk works fine for:


It also runs for:


It does not run for:


So apparently the problem is in GUI.ahk. And I think I know what is the problem: GUI.ahk looks like this:


I think the problem is that AutoHotKey parses the sequence of includes as if it was parsing just a single file, line after line. I think it parses the "global" part of Far.ahk as if it was a code belonging to GUI_Download_Download label (so it won't get executed until I actually show the GUI and the user clicks the Download button). Which is a rather logical way to behave, but presents a problem that needs to be addressed: How to tell the AutoHotKey parser that "a block ends here, any further commands once again belong to the main block".

That is an error indeed, but as the window always exists, it's not a problem in this case.

For now I have fixed the problem by changing the order of the includes so that GUI.ahk is the last one, but I think this is an issue that needs to be addressed in a more systematic way.

Yes, but this addressing has to be done by yourself. this is not an AHK issue.
1) you should write your scripts very clean. E.g. end the autoexec section of each script with a return, exit each script nicely, etc.

2) you can use this setting to run all auto-exec section of the included files.

_________________
Ciao
toralf

Isn't it? I think it is, because AutoHotKey doesn't give me any keyword that would mark an end of a block. Or at least I don't know that keyword. So the only way I can solve this issue is through rearranging the code to make sure no included file will end with something which could be interpreted as an open block. Which might be rather problematic and leads to far less-readable scripts. I should think that a simple (optional) EndBlock would be more useful.

Think of #Include as though it does a copy and paste of the included file.

In other words, #Include is designed to be only a simple mechanism for bringing in external files. It isn't designed to merge the auto-execute sections of two or more scripts into one big auto-execute section.

A future version may have a #Merge directive or similar means of merging scripts.

The keyword exists, it is "return".

_________________
Ciao
toralf