That's a good option, let the user specify a handler(function)...

AutoHotkey v1.1.10 Alpha Release
No, you misunderstand; I'm talking about executing the g-label in a similar way to how OnMessage handlers execute their functions (the internal implementation, that is); and it does not involve re-sending/posting the message.That's a good option, let the user specify a handler(function)...

I see, I look forward to how it turns out...what are the possible side-effects though?

As far as I understand none. If OnMessage WM_NOTIFY handlers have always worked without hanging the script, this approach should also work.what are the possible side-effects though?

I guess it's the best option...

fincs: Where can I download the updated .exe?

You'll have to wait for Lexikos to update the alpha, as I believe he wouldn't want people posting random binaries.fincs: Where can I download the updated .exe?

v1.1.10-alpha2 uploaded; includes fincs' fix.

Thank you very much. Sound managment has an ease of use for win6+ users.

In most instances, some commands and also control flow statement(s [specifically if-else], within the subroutine of the control's associated target label(g-Label), resulted to some weird behavior. Tested on ComboBoxEx, (not sure if it's due to A_GuiEvent representing varied control-specific structs depending on the notification, NMHDR is always the first member though). Every time a notification is sent via WM_NOTIFY, opening the ComboBoxEx's dropdown listbox would cause it to slide up an down repeatedly before settling to a halt. Then it would need to clicks to select an item. Removing the g-label fixes this though.

What about using the well-tried PostMessage method with
- WM_COMMAND : A_GuiEvent = "WM_COMMAND" or "C", A_EventInfo = HIWORD(wParam)
- WM_NOTIFY : A_GuiEvent = "WM_NOTIFY" or "N", A_EventInfo = code field of NMHDR structure
If one wants to get more informations on specific notifications OnMessage() will accomplish that and additionally allow to return a specific value when needed.

Prefer ahkscript.org for the time being.
The point of this built-in support is precisely not needing to use DllCall or OnMessage (especially since the latter always captures messages for all windows and there's no HWND filtering system).If one wants to get more informations on specific notifications OnMessage() will accomplish that and additionally allow to return a specific value when needed.
Also, currently this is calling the subroutine in a similar way to how OnMessage() dispatches message handlers, so in theory there shouldn't be "weird behaviour" (I personally haven't been able to reproduce what Coco is seeing; possibly it's a bug in his script) unless I'm missing something.
EDIT: by the way, could you post here a test case for the so-called "weird behaviour"?

... and additionally allow to return a specific value when needed.

Prefer ahkscript.org for the time being.
Currently zero is always returned, although it could be changed so that ErrorLevel is returned to the message sender. Most controls appear to ignore the return value of WM_NOTIFY so this should not be an issue.How could this be done with your attempt?
It would be certainly useful to have per-window OnMessages.BTW: If Custom controls will be implemented, it's time to implement "on control" message handlers.
EDIT: Lexikos, would this be OK?
EDIT2: Simplified approach.
