ex_this - add to the auto-execute section from anywhere in your script

[davebrny]

Code: Select all

;execute_this
;execute_end

;exit_this
;exit_end

if all of your scripts are split up into individual files and included into one main script then there can be a bit of going back and forth between the current file and the auto-execute section any time you need to change something there
ex_this() solves this problem (in most cases) by letting you add to the auto-execute section (or exit subroutine) from anywhere in your script

it also solves the problem of getting "label not found" errors when you remove a file but forgot to remove the goSub or timer that was in the auto-execute section

another benefit of using this method is that sharing code with others becomes easier since everything is self contained in one file.
if the person youre sharing a script with is also using ex_this() then all they have to do is include it into their own script and reload to get things up and running.
if theyre not, then the execute/exit tags can act sort of like instructions about which parts need to be copied to auto-execute section of their script

lastly, since the execute/exit tags are just comments, they dont have any effect if someone decides to run the script it on its own


drawbacks

ex_this() copies the code between the execute/exit tags and then stores it in \AppData\Local\Temp\ex_this\
this means means that msgBox errors will show that location and not the source file, as will certain variables such as a_lineFile.

in certain situations you might be able to work around these problems by using the "goto error" timer or by using the following function to convert a_lineFile to the actual source file

Code: Select all

source_file := ex_source(a_lineFile)

i havnt tested this it out in all the different situations it could be used in yet so there are probably more drawbacks than the ones listed above.
also, i have around 100 or so separate files included into my main script and i use about 15 execute/exit_this tags so i cant say for sure how well this will work if it has to scan 1000s of files every time you reload


other methods?

i had this idea a while back and just went and made it without thinking too much about different ways of doing it, so i would be curious to know if there are any alternative or better ways that ive missed



more words n stuff in the gist readme

gist code

[Nextron]

it also solves the problem of getting "label not found" errors when you remove a file but forgot to remove the goSub or timer that was in the auto-execute section

Sounds familiar. Instead of moving code blocks of apart, between auto-execute and the rest, I used to keep it together and just GoSub to it as well.

other methods?

Now I prefer to put any auto-executing part of a piece of code in its own function and calling itself as a static variable (remember setting any variables global, where needed). Similarly, setting a destructor (naming?), works as an OnExit replacement:

Code: Select all

YourApplicationAutoExecute(dummy:=""){
	static init:=YourApplicationAutoExecute()
	,_:={base:{__Delete: "YourApplicationAutoExecute"}}
	
	
	If (init=0){
		;Startup
		
		Return 1
	}
	
	if !(_){
		;Shut down
		
		Return 
	}
	Return
}

The order of execution of this code is something to take into account, as the static variables are set prior to auto-execute, so these lines run before it as well, meaning that any auto-execute commands changing AHK defaults such as SetTitleMatchMode have not been run either. Since AHK is still initializing at this point, there are some other limitations, but I didn't bother to remember those .
But this has suited me well, and code set up like this is portable and can just be pasted in any location of an existing script and expected to run as intended.

[iPhilip]

Hi Nextron,

Thank you for your interesting YourApplicationAutoExecute() function. Unfortunately, as posted, it doesn't do what you suggested. Here is a version that does so:

Code: Select all

YourApplicationAutoExecute(){
	static init:=YourApplicationAutoExecute()
	,_:={base:{__Delete:"YourApplicationAutoExecute"}}
	
	if (init="") {
		;Startup
		MsgBox starting...
		Return 1
	} else {
		;Shut down
		MsgBox shutting down...
      Return
	}
}

Cheers!

[davebrny]

Now I prefer to put any auto-executing part of a piece of code in its own function and calling itself as a static variable

thats a neat trick. a lot more elegant as well

[Barney]

Or use a class:

Code: Select all

class DietOrganizer
{	
	__New(){
		static _ := new DietOrganizer()
		_ :=""
		MsgBox,  hello world
	}
	
	__Delete(){
		MsgBox,  bye world
	}
}

[Nextron]

Unfortunately, as posted, it doesn't do what you suggested. Here is a version that does so

That's odd; for me it does work. What's not working properly for you?
Additionally, I usually put other code in the same function, so it gets called more often then just at start/exit but it only needs to perform its start/exit code at the appropriate time. Using the alternative code would not suffice for me.

[iPhilip]

Hi Nextron,

I tested your code with MsgBox statements inside the if statements as follows:

Code: Select all

YourApplicationAutoExecute(dummy:=""){
	static init:=YourApplicationAutoExecute()
	,_:={base:{__Delete: "YourApplicationAutoExecute"}}
	
	
	If (init=0){
		;Startup
		MsgBox start
		Return 1
	}
	
	if !(_){
		;Shut down
		MsgBox end
		Return 
	}
	Return
}

The MsgBox start statement never gets executed because init != 0. Rather, during the initialization phase init = "" is true. I understand that the alternative code I provided doesn't meet your needs. Perhaps, this form would do so:

Code: Select all

YourApplicationAutoExecute("hello")

YourApplicationAutoExecute(dummy:=""){
   static init:=YourApplicationAutoExecute()
   ,_:={base:{__Delete: "YourApplicationAutoExecute"}}
   
   If (init=""){
      ;Startup
      MsgBox startup
      Return 1
   } else if !(_){
      ;Shut down
      MsgBox shutdown
      Return 
   } else {
      MsgBox %dummy%: other code goes here
   }
}

Cheers!

[lexikos]

,_:={base:{__Delete: "YourApplicationAutoExecute"}}

The problem with this approach is the reverse of initialisation, only a little worse. The function executes after objects in global variables (such as classes) are released.

Instead, you should use OnExit() within the initialisation function's main body (not a static initialiser).

[iPhilip]

Hi lexikos,

Thank you for pointing that out. Could you provide a simple example showing the problem and solution?

Thank you.