OnAutoItExit Handler

[MrCreatoR]

Hi,

This Include-UDF idea was inspired from Feature Request on Bug Tracking System about a better OnAutoItStart/OnAutoItExit handling. So here it is:

Example:

#include <OnAutoItExit_Handler.au3>

_OnAutoItExit_AddFunc("MyTestFunc", "Some data")
_OnAutoItExit_AddFunc("MyTestFunc2", "Some other data")

Sleep(1000)

;_OnAutoItExit_RemoveFunc("MyTestFunc")

Func OnAutoItExit()
    ;If we have our own OnAutoItExit function, OnAutoItExit_Handler will add ("pick up") this function to the handler :)
    ;It's helpfull when this function is defined by some UDF that we using in our scripts.
    MsgBox(64, "Exit Results 1", "Exit Message from OnAutoItExit()")
EndFunc

Func MyTestFunc($sParam)
    MsgBox(64, "Exit Results 2", 'Exit Message from MyTestFunc("' & $sParam & '")')
EndFunc

Func MyTestFunc2($sParam)
    MsgBox(64, "Exit Results 3", 'Exit Message from MyTestFunc("' & $sParam & '")')
EndFunc

Notes:

* This include is usefull for the UDF writters, to let them set OnAutoItExit() function to free some resources, perhaps in the future i should add an option to check constantly the Opt("OnExitFunc") and add to the list if new function was set.

* If you are including some UDF that uses OnAutoItExit function, then «OnAutoItExit Handler» UDF will "catch" that function and call it when script is exits.

* OnAutoItStart() function can not be handled as OnAutoItExit() function (due to the lack of ability of changing it's name, and also because when it's called there is no variables declared and we can not add other function calls by func), but we still can add a multiple functions from inside OnAutoItStart function, example:

Func OnAutoItStart()
    Local $aOnAutoItStart_Funcs = StringSplit("OnAutoItStart_1|OnAutoItStart_2", "|");Add here as many as you need
    
    For $i = 1 To $aOnAutoItStart_Funcs[0]
        If $aOnAutoItStart_Funcs[$i] = "OnAutoItStart" Then ContinueLoop;Prevent recursion error
        Call($aOnAutoItStart_Funcs[$i])
    Next
EndFunc

But it's not so practical (not usefull), since we can't use it to overcome other UDF's defined function (OnAutoItStart()).

========================================================

Download: OnAutoItExit_Handler.zip

[FireFox]

@MrCreator

dont know why nobody reply to your udf... (same thing for my AVICapture)

But i think its great idea mate

Cheers, FireFox.

[martin]

Hi,

This Include-UDF idea was inspired from Feature Request on Bug Tracking System about a better OnAutoItStart/OnAutoItExit handling. So here it is:

Example:

#include <OnAutoItExit_Handler.au3>

_OnAutoItExit_AddFunc("MyTestFunc", "Some data")
_OnAutoItExit_AddFunc("MyTestFunc2", "Some other data")

Sleep(1000)

;_OnAutoItExit_RemoveFunc("MyTestFunc")

Func OnAutoItExit()
    ;If we have our own OnAutoItExit function, OnAutoItExit_Handler will add ("pick up") this function to the handler :)
    ;It's helpfull when this function is defined by some UDF that we using in our scripts.
    MsgBox(64, "Exit Results 1", "Exit Message from OnAutoItExit()")
EndFunc

Func MyTestFunc($sParam)
    MsgBox(64, "Exit Results 2", 'Exit Message from MyTestFunc("' & $sParam & '")')
EndFunc

Func MyTestFunc2($sParam)
    MsgBox(64, "Exit Results 3", 'Exit Message from MyTestFunc("' & $sParam & '")')
EndFunc

Notes:

* This include is usefull for the UDF writters, to let them set OnAutoItExit() function to free some resources, perhaps in the future i should add an option to check constantly the Opt("OnExitFunc") and add to the list if new function was set.

* If you are including some UDF that uses OnAutoItExit function, then «OnAutoItExit Handler» UDF will "catch" that function and call it when script is exits.

* OnAutoItStart() function can not be handled as OnAutoItExit() function (due to the lack of ability of changing it's name, and also because when it's called there is no variables declared and we can not add other function calls by func), but we still can add a multiple functions from inside OnAutoItStart function, example:

Func OnAutoItStart()
    Local $aOnAutoItStart_Funcs = StringSplit("OnAutoItStart_1|OnAutoItStart_2", "|");Add here as many as you need
    
    For $i = 1 To $aOnAutoItStart_Funcs[0]
        If $aOnAutoItStart_Funcs[$i] = "OnAutoItStart" Then ContinueLoop;Prevent recursion error
        Call($aOnAutoItStart_Funcs[$i])
    Next
EndFunc

But it's not so practical (not usefull), since we can't use it to overcome other UDF's defined function (OnAutoItStart()).

========================================================

Download: OnAutoItExit_Handler.zip

Thanks MrCreatoR, a neat solution to an old irritation. If the OnAutoItExit handling gets improved then we will be able to cope with more than 1 udf which has an OnExit function, meanwhile this is good and covers nearly all requirements IMO.

Now I would be interestd to see you do the same for udfs which have, or should have, things like WM_COMMAND functions

[MrCreatoR]

Now I would be interestd to see you do the same for udfs which have, or should have, things like WM_COMMAND functions

I am not sure i follow your thought here ...

[martin]

I am not sure i follow your thought here ...

It could be because my thoughts are wrong. Some udfs register their own functions for WM_COMMAND. _EIPListView.au3 is one example. If you use this udf and want to register WM_COMMAND for some reason then you have to modify the udf. It would be better if you could register events for controls by having a function which added cases to a global WM_COMMAND handler. Or have I misunderstood something?

[MrCreatoR]

It could be because my thoughts are wrong. Some udfs register their own functions for WM_COMMAND. _EIPListView.au3 is one example. If you use this udf and want to register WM_COMMAND for some reason then you have to modify the udf. It would be better if you could register events for controls by having a function which added cases to a global WM_COMMAND handler. Or have I misunderstood something?

I don't think we can do it. There will be a problem because we can't (?) check the current registered WM_* function and set another one to call the old one. If GUIRegisterMsg() was returning the current function name that is registered to specific message, then it would be possible.