How to use TextOut without processing WM_PAINT?

[Arjay]

Basically window message processing is put in another thread. So if I put the drawing job(for example, TextOut) in WM_PAINT, the main thread won't be very responsive since WM_PAINT is processed very often in another thread. So that is why I like to put the drawing job in some message other than WM_PAINT. Hopefully I explain myself very well. Thanks.

All window message processing should be performed in the main UI thread.

Of course, you don't need to do it this way, but if you don't you might run into problems.

[LarryChen]

All window message processing should be performed in the main UI thread.

Of course, you don't need to do it this way, but if you don't you might run into problems.

May I ask why window message processing should be performed in the main UI thread? What kind of problems I might run into if I choose not to process messages in main thread? Thanks

[VictorN]

May I ask why window message processing should be performed in the main UI thread? What kind of problems I might run into if I choose not to process messages in main thread? Thanks

You may get a deadlocks.
Now may I ask you why you think you need to process messages in a thread the window does NOT belong to?

[LarryChen]

You may get a deadlocks.
Now may I ask you why you think you need to process messages in a thread the window does NOT belong to?

Ok, I have a parent window and a child window. The parent window belongs to the main thread and the child window belongs to a sub thread. The window messages in topic are processed in the sub thread. Now I want the sub thread to process some window message to do the drawing job for child window. Why am I going to get a deadlock in such a scenario? Thanks.

[VictorN]

Ok, I have a parent window and a child window. The parent window belongs to the main thread and the child window belongs to a sub thread.

But why does the child window belong to a sub thread?
What are you trying to accomplish with so strange design?

[LarryChen]

But why does the child window belong to a sub thread?
What are you trying to accomplish with so strange design?

Because parent window belongs to the main thread and for some reasons I can't access the parent window message processing. So in order to process child window message, I have to have sub thread to handle child window message. Base on such a situation, what is the best way to do then? Thanks.

[VictorN]

Because parent window belongs to the main thread and for some reasons I can't access the parent window message processing.

And what are those "reasons"?

So in order to process child window message, I have to have sub thread to handle child window message. Base on such a situation, what is the best way to do then? Thanks.

The best way would be to process child window messages in the main UI thread, And the child window should belong to the same thread as the parent one.

[LarryChen]

And what are those "reasons"?


The best way would be to process child window messages in the main UI thread, And the child window should belong to the same thread as the parent one.

If child window messages are processed in the main thread, it will block parent window messages. As the result, parent window will hang there. Thanks.

[VictorN]

If child window messages are processed in the main thread, it will block parent window messages.

Why? How did you design this processing?

[Arjay]

May I ask why window message processing should be performed in the main UI thread? What kind of problems I might run into if I choose not to process messages in main thread? Thanks

The generally accepted approach for multi-threaded Win32 applications is to put all the windows in the main UI thread and put the processing/data retrieval operations into worker threads. PostMessage is generally used by the worker threads to signal the UI thread that new data is present or has been processed.

Surely, you've read books or have come across some internet articles that talks about this approach?

[Igor Vartanov]

If child window messages are processed in the main thread, it will block parent window messages. As the result, parent window will hang there. Thanks.

All the thread's messages come to the same message queue belonging to the thread.

If child window message blocks parent window messages, this indicates that main message pump gets blocked. Does your child window run modal? And if yes, why you solve the parent's issue by moving child to a separate thread, but not just running modeless?

And if not, your child window messages even being processed in other thread must be blocked as well, doesn't matter if you can see any signs of that or not.

During all this thread guys are trying to hint you that your approach is basically wrong somewhere. And I tend to agree with them. Your initial question regarding TextOut clearly demonstrates that you miss very, very basic things in GUI programming.

The answer why you should not use TextOut outside WM_PAINT handler is extremely simple. Paint message is placed to message queue whenever Windows decides. Please, read this twice: Windows decides on its own when your program must re-paint your window.

The obvious concequence is: in case your paint handler does not include every single aspect of window rendering, any part or visible element of your window can be just wiped off just by the very fact of forced repaint.

[OReubens]

The answer why you should not use TextOut outside WM_PAINT handler is extremely simple. Paint message is placed to message queue whenever Windows decides. Please, read this twice: Windows decides on its own when your program must re-paint your window.

The obvious concequence is: in case your paint handler does not include every single aspect of window rendering, any part or visible element of your window can be just wiped off just by the very fact of forced repaint.

THIS !!!

While you can technically do painting/drawing outside of WM_PAINT (and WM_ERASEBKGND, and WM_NCPAINT and a couple others). You may find your attempts have undesired/weird sideeffects that make it not work entirely how you wanted.

More often than not, attempting to paint outside of the windows painting cycle is a dead giveaway that you have a fundamental design flaw in your program.
The right way to go is to make all painting happen as part of WM_PAINT.
And yes, I am aware there are exceptions to the rules, but in that case you better be 100% sure of what you're doing.


if you need to force a repaint of a (portion of a) window as a result of other messages, then the right way to do it is to call InvalidateRect() to invalidate the area, and then some time later, Windows will fire a WM_PAINT so you have a chance at actually repaining that part of the window.
If the "some time later" of Windows doesn't give you the results fast enough, you can enforce a repaint right away by calling UpdateWindow() right after the call to InvalidateRect(). Again, be sure why you're doing this because it can have massive adverse effects on performance when used incorrectly.

[LarryChen]

And if not, your child window messages even being processed in other thread must be blocked as well, doesn't matter if you can see any signs of that or not.

Yes, my child window IS a modeless dialog. What do you mean "your child window messages even being processed in other thread"? What is exactly "other thread" here? Basically I have two threads. One is main thread and another one is I can call worker thread. So when you said other thread, what thread were you talking about? Thanks.

[VictorN]

So when you said other thread, what thread were you talking about?

"other thread" is usually any non-main (worker) thread.
And the main thread in a Windows GUI application is usually a GUI thread.

[LarryChen]

Actually the tough part is that I can't access message processing in main window. As the result, in order to process WM_PAINT for child window, I have to process it in another thread. Since child window keeps sending WM_PAINT whenever it is displayed, so WM_PAINT will block any message sent by main window. I am just thinking if it is possible to intercept the messages in main window so that I can process WM_PAINT from child window in main thread? Thanks.