GUIRegisterMsg()

[Yashied]

How can I get a pointer or the name of the function registered for the window message? Is it possible to make a chain of handlers known window messages?

Thanks.

GUIRegisterMsg($WM_..., 'MY1_WM_...')
$sWMOld = ...
GUIRegisterMsg($WM_..., 'MY2_WM_...')

Func MY1_WM...($hWnd, $iMsg, $wParam, $lParam)
    Return 'GUI_RUNDEFMSG'
EndFunc   ;==>MY1_WM...

Func MY2_WM...($hWnd, $iMsg, $wParam, $lParam)
    Return Call($sWMOld, $hWnd, $iMsg, $wParam, $lParam)
EndFunc   ;==>MY2_WM...

[BrettF]

Maybe explain why exactly you need this?

[Yashied]

Maybe explain why exactly you need this?

I foresee this question. I wrote a UDF, which uses WM_ACTIVATE. I want people who will use my UDF, can also use this window message in their code (if necessary), together with my UDF. In this case, I could register its function to the message, and then restore the user function. Of course, I use _WinAPI_SetWindowLong() and _WinAPI_CallWindowProc(), but GUIRegisterMsg() is more reliable and easy to use. I hope I satisfied your curiosity.

[MrCreatoR]

Yes, i also thought about it some time ago. We need GUIRegisterMsg() to return old registered message function. Or/And to be able to set the same WM message for different functions (so them bouth will be called when the message is recieved).

[Mat]

On this note... I was looking at this a while ago too, after an edit control was swallowing my mouse wheel message. That somehow blocked me from reregistering it aswell.

is there a way to return the current function registered with that msg?

MDiesel

[MrCreatoR]

Well, actualy we could use a custom function + global variable:

Global $sLAST_REGISTERMSG_FUNC = ""

$sLast_RM_Func = _GUIRegisterMsg($WM_..., "WM_...")

Func _GUIRegisterMsg($nMsg, $sFunction)
    Local $sRet_RM_Func = $sLAST_REGISTERMSG_FUNC
    $sLAST_REGISTERMSG_FUNC = $sFunction
    
    GUIRegisterMsg($nMsg, $sFunction)
    
    Return $sRet_RM_Func
EndFunc

But that does not solve the issue with UDF creation, it forces all users to use this custom function, wich is the same as telling to them that they must be aware of WM_* usage by the UDF.

[Valik]

This is not a trivial problem to solve. It is trivial to change the code to build a callback chain similar to AdlibRegister(). The problem is are existing functions written correctly to be chained? The correct behavior is to use a stack-based chain (last registered, first called) chain. The chain should only continue if the function returns $GUI_RUNDEFMSG. If a function returns anything else then the next function in the chain is NOT called. The last function in the chain would always be the internal AutoIt code. However, as I mentioned, are the existing UDF's written correctly? Do they all correctly return $GUI_RUNDEFMSG? Or is fixing this going to basically break all current callbacks?

Also, we need to stop and write a proper class and an interface so that all callbacks (Hotkey, GUI, Adlib, Call, et all) can pass through the same code which should support features like #14.

So there are design issues both internally with the implementation and with how it works in the language itself. Plus there's the whole time factor, or more specifically a lack-there-of.

[Yashied]

Opt("OnExitFunc", ...) also returns the previous value, but most people who write UDF, do not care about those who use it and want to use OnAutoItExit() in their code. As a result, function just will not work, as is already used inside UDF, but the author has not taken care to continue the chain.

[Valik]

Opt("OnExitFunc", ...) also returns the previous value, but most people who write UDF, do not care about those who use it and want to use OnAutoItExit() in their code. As a result, function just will not work, as is already used inside UDF, but the author has not taken care to continue the chain.

I suggest you get with the times.