Library - Preserve autoexecute section? Topic is solved

[sancarn]

I'm trying to maintain the CGUI library for ahk.

https://github.com/sancarn/CGUI

One thing I noticed is that if you include CGUI at the top of your script like:

Code: Select all

#include CGUI.ahk
;do stuff
return

Your code simply doesn't execute. It will only execute if the include statement is present after the return statement:

Code: Select all

;do stuff
return
#include CGUI.ahk

Is there a quick-fix which I could make to the CGUI files to allow both include conventions to work simultaniously? Or will I have to go through each file to identify the culprit script which is halting the auto-execution section?

[gregster]

There might be more code sections in the other included files that could interrupt the auto-execute section of the main script. But these labels in CGUI.ahk, ending with returns, are certainly in the way:

CGUI.jpg (27.71 KiB) Viewed 2155 times

Now, how to possibly modify the library is some other question...

[Helgef]

Why do you want it at the top? Put it at the bottom, or use goto.

[swagfag]

Code: Select all

Goto End_CGUI
#NoEnv
Class CGUI
{
	...
	...
	...
}

#include %A_LineFile%\..\gdip.ahk
#include %A_LineFile%\..\CControl.ahk
#include %A_LineFile%\..\CFileDialog.ahk
#include %A_LineFile%\..\CFolderDialog.ahk
#include %A_LineFile%\..\CEnumerator.ahk
#include %A_LineFile%\..\CMenu.ahk
End_CGUI:

assuming those labels are handlers and not actually something that needs autoinitializing

[guest3456]

https://www.autohotkey.com/docs/Scripts.htm#auto

After the script has been loaded, it begins executing at the top line, continuing until a Return, Exit, hotkey/hotstring label, or the physical end of the script is encountered (whichever comes first).

[jeeswg]

swagfag's looks like the best quick-fix solution, put a goto at the top of the file, and a label at the bottom of the file.

You need the goto to skip the method call and return line that gregster indicated, the return line prematurely ends the auto-execute section.

The fuller solution is to replace labels with functions.

[sancarn]

Why do you want it at the top? Put it at the bottom, or use goto.

Personally I always prefer to have all my includes at the top, mainly because that's how I'd do it in any other language (C/C#/Ruby/Node/Python/...). I assume others are the same. Anyway this is besides the point. The point is, the library should be designed in such a way that it just works however you include it. As is, the library works sometimes and not others... That's terrible library design imo.

The fuller solution is to replace labels with functions.

Indeed I did this in CMenu.ahk. My only concern there is the amount of refactoring it might entail... I don't know the full code base yet so couldn't say for certain how much CGUI uses global variables, goto statements etc. So yeah currently am a little hesitant to go down that route....

Code: Select all

Goto End_CGUI
#NoEnv
Class CGUI
{
	...
	...
	...
}

#include %A_LineFile%\..\gdip.ahk
#include %A_LineFile%\..\CControl.ahk
#include %A_LineFile%\..\CFileDialog.ahk
#include %A_LineFile%\..\CFolderDialog.ahk
#include %A_LineFile%\..\CEnumerator.ahk
#include %A_LineFile%\..\CMenu.ahk
End_CGUI:

assuming those labels are handlers and not actually something that needs autoinitializing

Ay! That is a great quick fix! I'll definitely give this one a go as it seems to be the easiest quick fix there is! Thanks!

[sancarn]

Hmm unfortunately a label can't point to a function, so if it was done like swagfag suggested the following wouldn't work:

Code: Select all

;do stuff
return
#include CGUI.ahk
someFunc(){

}

So here's a quick hack which resolves the ahk error!

Code: Select all

Goto End_CGUI
#NoEnv
Class CGUI
{
	...
	...
	...
}

#include %A_LineFile%\..\gdip.ahk
#include %A_LineFile%\..\CControl.ahk
#include %A_LineFile%\..\CFileDialog.ahk
#include %A_LineFile%\..\CFolderDialog.ahk
#include %A_LineFile%\..\CEnumerator.ahk
#include %A_LineFile%\..\CMenu.ahk
End_CGUI:
_:=_

[jeeswg]

This would trigger an error:

Code: Select all

#Warn
_:=_

As would var2 := var1, if var1 was not previously assigned.

Handling #Warn is something worth considering if sharing your scripts widely. I.e. assigning variables, and using 'local' in functions, where appropriate, to avoid triggering #Warn errors.

[sancarn]

This would trigger an error:

Code: Select all

#Warn
_:=_

As would var2 := var1, if var1 was not previously assigned.

Handling #Warn is something worth considering if sharing your scripts widely. I.e. assigning variables, and using 'local' in functions, where appropriate, to avoid triggering #Warn errors.

Thanks for the heads up. I think long term I'll be refactoring the code to use functions like you suggested

[Helgef]

I always prefer to have all my includes at the top

I suggested goto only if there was an actual need to have the library at the top, eg, for static var initialisation order. Using work arounds such as those suggested here, only for the reason of having the include at the top, are terrible program design imo.

_:=_

If you must have it point to something useless, use an empty block instead, or put the label above the code you actually want to execute

cheers.