AutoHotkey Community

Since the OnMesage() AHK function only monitors messages send to an
AHK script, i searched the forum for a "workaround" and found this thread. http://www.autohotkey.com/forum/topic19367.html+message AFAI understand JGR wrote a global Hook.dll that allows to monitor system near messages.

My understanding of such things is limited, i'm a it technican not a coder but i need to monitor WM_COMMAND messages from a 3party app, so better ask a coder for this.

Sean, majkinetor, JGR could you look into this please. Is it possible to hook the message to get the control ID and HWND of the sending window?

If so could you provide an example please?

Thank you in advance

~Slaya

I suggest you to bump the orginal topic by posting a link to this post.

Slaya:

There are several ways which you could go about this.

SetWinEventHook could be used, but this would probably be tricky to determine the WM_COMMAND parameter, and might have mixed reliability (ie. buttons versus menus, etc.)
However if you can just get away with monitoring button clicks, etc. by EVENT_OBJECT_INVOKED, then this requires no dlls, and has minimal performance/stability issues.

A message hook using the hook.dll could be used, but this will likely cause noticeable performance issues.

I seem to remember that there is a get message hook as well? But I am not sure whether it would be suitable...

You could also inject a dll into the process and sub(super?)class the window procedure(s), but that would require another specialised dll, this would avoid the performance issues.

If autohotkey integration is not necessary, I would seriously suggest that you use SPY++ or similar.

PS. I would usually do some more basic research before posting, but as I am currently using a machine epic in its antiquity, where even browsing and typing is a trial, and I am tired, I can do without another saga of hangs and page faulting sprees, until I can use the better machine tomorrow... (This is a pentium pro running win98 with 80MB RAM). I've spent half an hour already on this post

After some research, it emerges that the only method from the above which could be done using the current dlls, and which would enable you to record WM_COMMAND ids and hwnds is the getmessage hook.
You would need to do a readprocessmemory on the last hook parameter to get the message structure, and all system messages would get funnelled through the autohotkey script.
The performance implications of this are so appalling that I think I'll just write a wndproc subclassing dll instead, and post some code for that in the coming day(s) when it's working...

JGR

If you succeed to do it for a generic subclassing, it'll be really a great feature, but to be honest I'm half doubtful about it.
I think it would be a lot simpler to extend the function reghook to accept the (target) ThreadID, so as to hook only that thread.

Thank you for looking into this JGR.
Will the new DLL only monitor WM_COMMAND Messages, or will it be more generic e. g. it will detect WM_CLOSE etc too?

~Slaya

I have just come back from holiday, and school starts tomorrow, so the chances of this happening soon are so close to zero that it is effectively abandoned until I can find a spare few days, in the upcoming year.

My apologies.

JGR

I am looking for a way to hook all wm_command messages to get the IDs for buttons, icon and so on too. JGR are you still busy or is it possible to show a way to do this?

Since 2007? That would be busy indeed.

Edit:
Much of that was wrong, rewriting post again...

It is perfectly possible to capture all message traffic using a WH_GETMESSAGE or perhaps WH_CALLWNDPROC SetWindowsHookEx via that hook dll, however this is clunky to implement and has *awful* performance implications.
The dll is most useful for low traffic, specific hooks like CBT.

Don't hold your breath on someone writing a generic subclassing dll.

I still maintain that you're better off using something like spy++, unless you actually need to automate the process...