views:

161

answers:

3

I'm aware that some messages types are sent directly to window procedures, while others are posted to a thread's message queue, but I haven't found any way to determine if a message will be sent or posted.

MSDN is half-helpful; it explained what's going on but the examples it gives are presumably not exhaustive.

Is there a definitive list of sent vs. posted messages, or a way to decide which type a message is?

A: 

The MSDN pages documenting each message should be considered the authoritative source for this:

The WM_LBUTTONDOWN message is posted when ...

The WM_SETFOCUS message is sent to a window after ...

etc.

Shog9
That works for messages where MSDN is clear, but then there are pages like http://msdn.microsoft.com/en-us/library/ms646360.aspx : "A window receives this message..."
Steve McKay
@Steve: Keep in mind, there are messages that are sometimes or always passed to your program without an explicit call to Send or PostMessage(). WM_SYSCOMMAND appears to be one that is always generated internally by the default window handler for other messages (non-client mouse, keyboard). You *might* still be able to catch it with a WH_CALLWNDPROC hook though, since that's what's happening under the hood (a direct call to the window procedure, *from* the default window procedure) - try it.
Shog9
+3  A: 

Use InSendMessage or InSendMessageEx to determine if you are processing a message that was sent by a call to the SendMessage function.

1800 INFORMATION
This does not appear to work for messages sent from the same thread.
Shog9
I'm approaching this from the perspective of a hook procedure, so I need to know at compile time whether to handle a message in a WH_GETMESSAGE or WH_CALLWNDPROC hook.
Steve McKay
+1  A: 

And some messages are neither posted nor sent. Such is the case of WM_PAINT, WM_TIMER and a few others. They are simply returned by GetMessage when the queue of posted messages are empty.

I'm not sure what applications you are trying to hook, but if you have to ask such questions, then I/m a bit scared. Nothing is more frustrating for a developer to spend time over user-reported crashes only to find out that the cause is from some other application that is injecting misbehaving code. Tread carefully!

Also, Spy++ (tool that ships with Visual Studio) will show you which messages are posted/sent/recevied for any given live windows app.

selbie