SendMessage
-
Hi The SendMessage function is used to send a message directly to a window procedure. Does this means that for messages received by SendMessage, the message loop( GetMessage & DispatchMessage) is not needed to process the message and call the windowproc. What happens internally on SendMessage? Welcome all suggestions Thanks Anil
-
anilFirst wrote:
to send a message directly to a window procedure.
no. It will go through the message loop. Why dont you try it for your self?
nave
Naveen R wrote:
no. It will go through the message loop.
No, it wont. Thats why its SendMesssage. As opposed to
PostMessage, which are posted to message loop.Prasad Notifier using ATL | Operator new[],delete[][^]
-
Naveen R wrote:
no. It will go through the message loop.
No, it wont. Thats why its SendMesssage. As opposed to
PostMessage, which are posted to message loop.Prasad Notifier using ATL | Operator new[],delete[][^]
-
Hi The SendMessage function is used to send a message directly to a window procedure. Does this means that for messages received by SendMessage, the message loop( GetMessage & DispatchMessage) is not needed to process the message and call the windowproc. What happens internally on SendMessage? Welcome all suggestions Thanks Anil
anilFirst wrote:
Does this means that for messages received by SendMessage, the message loop( GetMessage & DispatchMessage) is not needed to process the message and call the windowproc.
It depends on from what thread the message is "sent". If the message is sent from the thread that created the window, the message handler will get called directly without taking the detour of the message loop. If the message is sent from another thread, the receiving thread must be running a message loop since a context switch will be made to the receiving thread while the sending thread is blocked. This is also the reason why a deadlock situation can occur when sending messages from different threads and the receiving thread doesn't process messages. Have a closer look at MSDN documentation for
SendMessage()here[^] below the "Remarks" section.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
anilFirst wrote:
Does this means that for messages received by SendMessage, the message loop( GetMessage & DispatchMessage) is not needed to process the message and call the windowproc.
It depends on from what thread the message is "sent". If the message is sent from the thread that created the window, the message handler will get called directly without taking the detour of the message loop. If the message is sent from another thread, the receiving thread must be running a message loop since a context switch will be made to the receiving thread while the sending thread is blocked. This is also the reason why a deadlock situation can occur when sending messages from different threads and the receiving thread doesn't process messages. Have a closer look at MSDN documentation for
SendMessage()here[^] below the "Remarks" section.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownIn "Programming Windows" by Charles Petzold "Programs generally don't call window procedures directly. The window procedure is almost always called from Windows itself. A program can indirectly call its own window procedure by calling a function named SendMessage" So how the SendMessage and PostMessage invoke window proc's? What is internal working of both? Thanks Anil
-
In "Programming Windows" by Charles Petzold "Programs generally don't call window procedures directly. The window procedure is almost always called from Windows itself. A program can indirectly call its own window procedure by calling a function named SendMessage" So how the SendMessage and PostMessage invoke window proc's? What is internal working of both? Thanks Anil
What Charles Petzold meant with the statement you've quoted is probably that you seldom call a message handler directly as an ordinary function call. If you find yourself in a situation where you would like to call a message handler directly, you should call
SendMessage()with appropriate message ID as argument. I guess this is what Petzold refers to as being "called from Windows itself" since your using the Win32 API methodSendMessage().anilFirst wrote:
So how the SendMessage and PostMessage invoke window proc's? What is internal working of both?
This addresses the message management routines from a different perspective than the Petzold qoute. The qoute answers a question such as "how do I call a message handler from my code", but I understand your question to be more like "in what ways does a message handler get called when sending a message with SendMessage and PostMessage". A part of the answer for that question can be read in my previous post and also by following the MSDN link I provided. In addition: when posting a message with PostMessage(), the message is always placed in the message queue for the receiving window and retrieved with a call to
GetMessage(). The matching message handler is then usually determined by a switch-case statement and called with the parameters that came with the message.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Naveen R wrote:
So it directly call the window proc?
No exactly, but its system(windows) does that.
Prasad Notifier using ATL | Operator new[],delete[][^]
-
What Charles Petzold meant with the statement you've quoted is probably that you seldom call a message handler directly as an ordinary function call. If you find yourself in a situation where you would like to call a message handler directly, you should call
SendMessage()with appropriate message ID as argument. I guess this is what Petzold refers to as being "called from Windows itself" since your using the Win32 API methodSendMessage().anilFirst wrote:
So how the SendMessage and PostMessage invoke window proc's? What is internal working of both?
This addresses the message management routines from a different perspective than the Petzold qoute. The qoute answers a question such as "how do I call a message handler from my code", but I understand your question to be more like "in what ways does a message handler get called when sending a message with SendMessage and PostMessage". A part of the answer for that question can be read in my previous post and also by following the MSDN link I provided. In addition: when posting a message with PostMessage(), the message is always placed in the message queue for the receiving window and retrieved with a call to
GetMessage(). The matching message handler is then usually determined by a switch-case statement and called with the parameters that came with the message.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownMessageLoop ( GetMessage & DispatchMessage ) not needed in some cases. So it means that SendMessage() can call WindowProc directly. For a test case call UpdateWindow() before MessageLoop will invoke WindowProc directly. WindowProc will be called with WM_PAINT message. Then only the control comes to MessageLoop.
-
MessageLoop ( GetMessage & DispatchMessage ) not needed in some cases. So it means that SendMessage() can call WindowProc directly. For a test case call UpdateWindow() before MessageLoop will invoke WindowProc directly. WindowProc will be called with WM_PAINT message. Then only the control comes to MessageLoop.
anilFirst wrote:
MessageLoop ( GetMessage & DispatchMessage ) not needed in some cases. So it means that SendMessage() can call WindowProc directly.
Yes. In case the message is sent using
SendMessage().anilFirst wrote:
For a test case call UpdateWindow() before MessageLoop will invoke WindowProc directly. WindowProc will be called with WM_PAINT message. Then only the control comes to MessageLoop.
:confused: I don't understand what you mean. Is this a question? If you want to see how message handling works, I suggest you use your own user defined message ID. You cannot use WM_PAINT or WM_TIMER for this purpose since those messages are treated differently than other messages. Try sending with
SendMessage()and posting withPostMessage()from the main thread and see how the call stack differs in the two scenarios. Then try sending the message from another thread and you'll find that the call stack looks the same as if the message was posted from the main thread.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
anilFirst wrote:
MessageLoop ( GetMessage & DispatchMessage ) not needed in some cases. So it means that SendMessage() can call WindowProc directly.
Yes. In case the message is sent using
SendMessage().anilFirst wrote:
For a test case call UpdateWindow() before MessageLoop will invoke WindowProc directly. WindowProc will be called with WM_PAINT message. Then only the control comes to MessageLoop.
:confused: I don't understand what you mean. Is this a question? If you want to see how message handling works, I suggest you use your own user defined message ID. You cannot use WM_PAINT or WM_TIMER for this purpose since those messages are treated differently than other messages. Try sending with
SendMessage()and posting withPostMessage()from the main thread and see how the call stack differs in the two scenarios. Then try sending the message from another thread and you'll find that the call stack looks the same as if the message was posted from the main thread.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownI did try user defined message using SendMessage() before the message loop, soon after a call to CreateWindow() API. The message was send from main thread only. The windowproc received the User defined messages. This means that the message loop is not needed for SendMessage to deliver messages to WindowProc.