GUIRegisterMsg/GUIUnregisterMsg

[Melba23]

This is a reopening of Ticket 2624 now I have realised what asdf8 meant - and my apologies for not understanding it sooner.

Problem: Each time GUIRegisterMsg is called only the function defined in the latest call is fired when the message is received. This makes it difficult to use message handling in UDFs - it requires the user to realise that they need to add a UDF handler function inside an existing handler function if both are to be fired when required and not rely on an internal UDF handler registering function (see my GUIListViewEx UDF for an example of how this can work).

Feature Request: Allow multiple functions to be called when a message is received in the same manner as Adlib, OnAutoItStartRegister & OnAutoItExitRegister. Then handlers could be registered/unregistered independently and each would be fired on message receipt without further coder intervention.

M23

[TicketCleanup]

Automatic ticket cleanup.

[chesstiger (autoit.de)]

You can use the API function SetWindowLong or SetWindowLongPtr to replace the WndProc of a window (implemented in WinAPI.au3 as _WinAPI_SetWindowLong). In your own WndProc you can grab and process any message, and, if required, call the original WndProc for calling windows internal features and such things like GUIRegisterMsg.

[anonymous]

@chesstiger:
Use SetWindowLong / SetWindowLongPtr API manually will cause processing window procedure slow although you do nothing in WndProc function (return DefWindowProc only). This will be seen clearly with painting message, your window will be tearing when drag/drop.
Also, using these WinAPI in AutoIT make your program does not exit in a nomal way (in Window Vista or later, you will see a compatibility-issue window suggest that your program ends unexpectedly)

[anonymous]

Replying to anonymous:

Also, using these WinAPI in AutoIT make your program does not exit in a nomal way (in Window Vista or later, you will see a compatibility-issue window suggest that your program ends unexpectedly)

If you crash when you app exits then you are probably not doing it right. I don't crash.

You should ask for help in the forum.

[anonymous]

If you crash when you app exits then you are probably not doing it right. I don't crash.

You should ask for help in the forum.

Normally, SetWindowLong/SetWindowLongPtr is safe. But it's not safe if you use it to subclass your window (pass nIndex= -4, so you replace window procedure function with your own function). Subclassing is dangerous.

In many case, you will not see every thing suggest that your app crash, but an exit code not equals to 1 in output window.

Also, manually subclassing is rarely discussed in the forum.

[Melba23]

chesstiger,

I agree that it can be done by subclassing in the UDF, but I also agree that subclassing is not simple and so would deter many from writing UDFs which required it. So I believe that it would be advantageous to have this facility in core code. It is also easy enough to arrange by using a UDF wrapper around separate GUIRegisterMsg calls, but then everyone would have to agree to use this UDF wrapper rather than the native function - and this idea has not found favour with the developers when I have suggested it in the past.

M23

[Melba23]

Jon has stated that this will not happen.

M23