is my understanding right ? about Windows Messages

[Dasar]

Hi all

I read iczelion tutorial about how to create a simple window, and some other stuffs, and I want to know whether I've understood it right, or I have some misunderstanding.

This is what I've understood:

* When something "event" happens to our window, The Windows put a Message in the Message Queue of our program.

* The Message loop of our program ( which contains GetMessage Function ) gets the message from the Message Queue. " Note: GetMessage function passes a pointer to a MSG structure to Windows OS, and then Windows OS FILL this structure with Message data, this FILLED structure is used then by TranslateMessage & DispatchMessage Functions" .

(( here I have my first question: does GetMessage removes the message from the message queue after the MSG structure is FILLED ? or deos Windows OS who is resonsible for this ?
in other words: who is the responsible for removing the "retrived Messages" from the Message Queue, and "when" exactly it removes the "retrived Message"  ?       ))


* The TranslateMessage function translate the Message that is in the " Filled MSG structure " and convert the row keyboard data to ASCIIZ data.

* The DispatchMessage sends the Message data that is in the " Filled MSG structre" to the appropriate Window Procedure, " DispatchMessage knows the appropriate Window Procedure by looking at the first member of the "FILLED MSG structure" ( which is the handle of the destination window "hwnd" ), and then DispatchMessage sends this paramter (hwnd) and all the other paramters to the Window Procedure of the destination Window.


as I understood,  Invoke DispatchMessage, Addr MSG    ,,,, is the same as ,,,    Invoke WndProc, msg.hwnd, msg.message, msg.wParam, msg.lParam

for example if MSG structure members are : hwnd = 333  , message = WM_ANYMESSAGE , wParam = 2 , lParam = How are you.

and we call DispatchMessage, Addr MSG ,,,  then it would be the same as if we do:   Invoke WndProc, 333, WM_ANYMESSAGE, 2, How are you.

So, in fact the calling of DispatchMessage is just calling to the WndProc and passing the MSG structure members as paramters to the WndProc function. !


is my understaning right ?


thank you in advance .

[PBrennick]

Dasar,

So, in fact the calling of DispatchMessage is just calling to the WndProc and passing the MSG structure members as paramters to the WndProc function. !

Essentially, that is correct, but the name of the procedure that is the default processor for messages can be anything. It is defined by the contents of  lpfnWndProc in the  WNDCLASSEX structure that is filled when you create the class for the window.

There are exceptions. You can use the IsDialogMessage API before the TranslateMessage and DispatchMessage APIs are invoked so that a dialog box can process messages, also. The Find command is a good example of this. Also, you can process messages right in the loop or translate keypresses to messages to be dispatched. This is an alternative method to using accelerator keys. If you wish to use accelerator keys, TranslateAccelerator will be used instead. TranslateAccelerator does not return until the window procedure has processed the message.  If a message has been processed, then you need to restart the loop instead of continuing on to the TranslateMessage and DispatchMessage APIs.

Since all these things can be done with the same message it stands to reason that the message is always available so every subclassed control can take a shot at it up until the TranslateMessage and DispatchMessage APIs are invoked. Everything must be done first.

Paul

[Dasar]

at first , Hi Paul
I'm glad to see you here, before a little moments I've read in another topic, and there was someone asks about you, he said that he didn't see since close to a week.
I hope your health is better now :) and thank you for your answer .

Since all these things can be done with the same message it stands to reason that the message is always available so every subclassed control can take a shot at it up until the TranslateMessage and DispatchMessage APIs are invoked. Everything must be done first.

so, the message is removed from the Message Queue after Translate and DispatchMessage are invoked ,  right ? this was my first question :)

thank you again .

[zooba]

The GetMessage function will remove the message from the queue. After GetMessage has returned, your MSG structure is the only remaining copy of the message.

You can call PeekMessage instead if you want to see if there is a message or see what it is without removing it.

DispatchMessage does just call your window procedure, as Paul said. However, it is documented as the way you should do it and I wouldn't try to "optimise" by skipping this call and sending the message directly. This is backed up by the CallWindowProc function (see description of lpPrevWndFunc) and a blog post by Raymond Chen explaining why you should let Windows call your window procedure for you.

Cheers,

Zooba :U

[Dasar]

zooba and Paul thank you for your answers, I got the info that I was looking for :)

[bf2]

This is backed up by the CallWindowProc function (see description of lpPrevWndFunc) and a blog post by Raymond Chen explaining why you should let Windows call your window procedure for you.

Does anyone know where this Raymond Chen blog post is now? The link gives me an 'Access denied' message.

I have searched Raymond's The Old New Thing blog but cannot find any blog that fits the description above.

[sinsi]

There was an extra %22 at the end of the URL

[dedndave]

not all messages go through the message queue
some are sent directly to the WndProc function
in some cases, the first occurance may go through the queue, but subsequent related events are sent to WndProc
this is true for things like WM_SIZE or WM_MOVE

http://msdn.microsoft.com/en-us/library/ms632586%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms632590%28v=VS.85%29.aspx