Quote Originally Posted by Igor Vartanov View Post
As I can see from your code, the text is provided via text_format structure. So why would you use native SetWindowText call?

In case you provide the text this way, the only thing you need to update the static window is InvalidateRect(hwndStatic, NULL, TRUE).

Besides, there's no need to do that in main thread, as entire Windows API is thread safe, and therefore you can InvalidateRect or SetWindowText immediately in context of your worker thread alright. Of course in case of InvalidateRect+WM_PAINT your text reading/writing must have a protection against simultaneous access, by means of critical section, for example.
The WM_PAINT handler is for the main window, its not for STATIC control. I was advised to never update window from another thread, so I changed it such a way that whenever the static control in needed to be updated with anew text the main window is sent a message(WM_APP) and in that message handler the new text is set. Prior to that I was simple updating the static controls from worker thread.


Quote Originally Posted by Igor Vartanov View Post
Yes, you're right, posting messages doesn't get along with pointers. But I cannot see any reason so far for passing pointers to notify your main thread to update static texts. (see above)


WM_USER came from Windows 3.x ages. Windows 95/NT provide new style common controls like list view, header bar, tool bar, etc., that internally use WM_USER. So to avoid any conflicts applications must use WM_APP and upper values for their custom messages.
Thanks