Does the Window Procedure specified as lpfnWndProc
by window class during registration runs in a separate thread ?

- 43
- 6
-
4Your first question is _awfully broad_. What does "really works" mean, really? I suggest you [edit] this question to only ask one, specific question. – Drew Dormann Jun 23 '21 at 18:41
-
Reference this (or similar) with a specific question - https://learn.microsoft.com/en-us/windows/win32/learnwin32/your-first-windows-program Include the code for the question in the question. – Richard Critten Jun 23 '21 at 18:49
-
@DrewDormann. I've removed the very "general/broad" part of my question. I'd really like to know if the `window procedure` runs in the main or separate thread... – Derek007 Jun 23 '21 at 19:54
-
1_"...runs in a separate thread ?"_ - No - it runs on the same thread as you called `CreateWindowEx` . See also https://stackoverflow.com/questions/4347404/changing-a-windows-message-loop-thread – Richard Critten Jun 23 '21 at 20:41
-
@RichardCritten, Ok. thx:-) – Derek007 Jun 23 '21 at 20:46
2 Answers
Does the Window Procedure specified as
lpfnWndProc
by window class during registration runs in a separate thread ?
No, it is called (as a callback) when events (aka messages) are dispatched by your message loop. In this way - the so-called 'event-driven' model - your program is able to react to user input as and when it happens without having to deal with any multi-threading or re-entrancy issues.
You might have more than one thread, but if it has windows associated with it (i.e. CreateWindowEx
was called by that thread) then it would need to have its own message loop.

- 24,133
- 4
- 26
- 48
-
The window procedure **is** re-entrant. That's the whole reason why the STA wasn't good enough and we had to invent the [ASTA](https://devblogs.microsoft.com/oldnewthing/20210224-00/?p=104901). – IInspectable Jun 23 '21 at 22:32
There is an important concept in windows called the message loop
.
It is usually inside the main function (aka: WinMain) and can be characterized in the following manner:
while (true) {
// blocks until there's a new message to process
GetMessage()
TranslateMessage()
// ends up calling the propper WndProc callback
DispatchMessage()
}
Update: When you create a window, the thread on which the window is created owns the windows (and the its message queue). Therefor, it must provide the message loop process. This is usually done in the application's main thread but, as other user stated, it can also be done in a separate thread.
The function DispatchMessage
takes care of executing the WindowProc
procedure of the window targeted by the message (as specified by the message's hwnd
parameter).
So, when you create a window, the lpfnWndProc
parameter specifies where you want to be notified for events (mouse clicks, keyboard presses, etc). And it is always called in the same thread (the application's main thread or the one which owns the window).
A word of advice: If you need to perform a potentially long operation as the result of an event, you must create a new thread (aka background worker) for the task, and perform some kind of IPC to notify the main thread when the function is finished.
You can find instructions about how to write a windows procedure here. Also, there is some info about the main loop in this wikipedia page.

- 6,437
- 19
- 30
-
2`DispatchMessage` calls the window procedure for *posted* messages. *Sent* messages call the window procedure either from inside `SendMessage` (if called from the thread that owns the window) or from inside `GetMessage()` (and it doesn't return to the message loop) – Ben Voigt Jun 23 '21 at 18:53
-
This is missing just about every important detail, and makes awfully misleading statements. There is no such thing as a *"main thread"*. There's a *"primary thread"*, but that isn't special in any way. It's the call to `CreateWindow` that establishes a window's thread affinity and defines the thread on which the window procedure is to be called. Frankly, this reads like you are regurgitating what you were taught without having digested the lessons. This shouldn't be the accepted answer. – IInspectable Jun 23 '21 at 22:30