Reputation: 678
I am new to win32 messages. I'd like to know that when a WindowProc is in the middle of processing a message, is it possible for it to be interrupted to process another message? Take the example below, if both [A] and [B] are executed, is it possible for the WindowProc to be interrupted to process the new WM_ACTIVATE and/or WM_ACTIVATEAPP message (as a result of the ShowWindow call) between [A] and [B]? If this is possible, are there any specific circumstances that make it so?
LRESULT CALLBACK WindowProc(
_In_ HWND hwnd,
_In_ UINT uMsg,
_In_ WPARAM wParam,
_In_ LPARAM lParam
{
...
case WM_ACTIVATEAPP:
if (wParam == FALSE)
{
// [A] Do something that would trigger a WM_ACTIVATE or WM_ACTIVATEAPP message to be queued to the message queue
ShowWindow(hwnd, SW_MINIMIZE);
// [B] Modify Window Styles
SetWindowLong(hwnd, GWL_EXSTYLE, WS_EX_CLIENTEDGE);
}
break;
...
}
Thanks for any comments!
Upvotes: 0
Views: 427
Reputation: 179819
No. That is the point of the GUI Thread - it's a single thread doing one thing at a time. If you're processing messages, you're not calling GetMessage
.
Upvotes: 1
Reputation: 5856
The system will never call this callback function while it is processing another message simply because all the messages are being put into a queue and (either your code or the framework you use, like MFC
) are dequeued one by one with no overlaps. Unless one message is finished being processed the control doesn't return back to the dequeueing block.
In fact you can safely treat your window
code as single-threaded. if you have multiple windows running in a single application they are all serialized and are still running in a single thread.
In fact you need to create separate threads if you want to run your windows (or workers) in parallel to each other.
Upvotes: 0