- Forum
- Windows Programming
- Nonqueued Windows Messages
Nonqueued Windows Messages
Hello all, I'm a long time visitor to the site, first time poster.
As I understand it, Windows sends nonqueued messaged straight to a program's WinProc, bypassing the message queue. My question is, if there is a queued message currently being processed, what will Windows do if it has a nonqueued message to send before the queued message is done being processed? Will it interrupt the current processing to call WinProc, or simply wait for any current queued-message processing to be done before calling WinProc?
Thanks in advance for any help.
-Andrew
As I understand it, Windows sends nonqueued messaged straight to a program's WinProc, bypassing the message queue. My question is, if there is a queued message currently being processed, what will Windows do if it has a nonqueued message to send before the queued message is done being processed? Will it interrupt the current processing to call WinProc, or simply wait for any current queued-message processing to be done before calling WinProc?
Thanks in advance for any help.
-Andrew
Take all of this with a grain of salt. It's been a while since I've done any WinAPI stuff.
---------------------
It depends where the non-queued message comes from. Windows has no control over the flow of your program (at least not unless something drastic happens, like a forced shutdown), so if your main thread is processing one message, it cannot be interrupted by another message until it returns. That's all there is to it. The only way your code can be interrupted is if you interrupt yourself (with something like SendMessage, in which case you'll process the message you're sending, then resume where you left off afterward).
However a new thread might be introduced if the message comes from elsewhere else (like another program trying to get cute and calling SendMessage to a window in another process -- which would probably crash). This is unlikely though. Any process that tries to access another process's WndProc directly is just asking for trouble. Usually (or always), inter-process communication is run through the message queue (via PostMessage). At which point your program will process it during the normal queue processing.
Pretty much: don't worry about it unless you use SendMessage. SendMessage is what skips the queue, everything else goes through the queue. Typically you only use SendMessage to manipulate controls, which is harmless. I don't think Windows will ever call SendMessage on you from an outside source.
---------------------
It depends where the non-queued message comes from. Windows has no control over the flow of your program (at least not unless something drastic happens, like a forced shutdown), so if your main thread is processing one message, it cannot be interrupted by another message until it returns. That's all there is to it. The only way your code can be interrupted is if you interrupt yourself (with something like SendMessage, in which case you'll process the message you're sending, then resume where you left off afterward).
However a new thread might be introduced if the message comes from elsewhere else (like another program trying to get cute and calling SendMessage to a window in another process -- which would probably crash). This is unlikely though. Any process that tries to access another process's WndProc directly is just asking for trouble. Usually (or always), inter-process communication is run through the message queue (via PostMessage). At which point your program will process it during the normal queue processing.
Pretty much: don't worry about it unless you use SendMessage. SendMessage is what skips the queue, everything else goes through the queue. Typically you only use SendMessage to manipulate controls, which is harmless. I don't think Windows will ever call SendMessage on you from an outside source.
Last edited on
Topic archived. No new replies allowed.