To Chris Boss: Message Watch question

[Gary Beene]

Chris,

I was reading your message watch code ... which raises obvious questions.

Do you know why some do, or some don't, go through the message loop?

I haven't used the loop in an app yet - the Callback functions have covered my needs so far - but I've been wondering what the advantage was of the loop for those of us who are programming mostly in DDT? From your post, apparently neither is a complete solution.

With what reading I've done so far, I'd have thought all messages would be captured by the loop - but apparently not. Don't I recall reading in Petzold's book that some messages don't go to a dialog at all - neither to the loop nor to the callback function? But I don't think he documented those which are not received by a dialog, nor do I find it in MSDN.

So how does a person guarantee that all messages can be received? Are SDK windows the only way to ensure access to all messages?

Thanks for the code you posted. I'll give it a try.

[Chris Boss]

Not all messages are treated the same.

Many messages generated by Windows can be sent by Windows directly to the window procedure of the receiving window (ie. WM_CREATE).

Other messages are generated by user input and need to be put into the message queue (which gets processed by the message loop and then forwarded to the window procedure).

The GetMessage API function gets messages from the message queue.

Windows does not processs these messages on a first come first serve basis. There is a specific order for pending messages and then first come first serve within each catagory which is as follows:

Sent Messages (SendMessage)
Posted Messages (PostMessage)
Input (hardware) and internal messages (ie. %WM_KEYDOWN)
Sent Messages (again)
WM_PAINT
WM_TIMER