win32: WM_PAINT calls but not supposed to be!

Question

I have a problem with WM_PAINT. Basically I want WM_PAINT to be called after a user WM_COMMAND, but for some reason it's called anyway in the main function.

 case WM_PAINT:
    {
     createFont();
     PAINTSTRUCT ps;
     HBRUSH hbruzh = CreateSolidBrush(RGB(0,0,0));
     HDC hdz = BeginPaint(hWnd,&ps);
     string s = "Memory Address";

     SelectBrush(hdz,hbruzh);
     SelectFont(hdz,hf);
     TextOut(hdz,0,0,s.c_str(),s.length());
     EndPaint(hWnd,&ps);

     DeleteObject(hbruzh);
     DeleteObject(hdz);

     break;
    }




int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
               LPSTR lpCmdLine, int nCmdShow)
{
    HWND hWnd;
    WNDCLASSEX wc;
    ZeroMemory(&wc, sizeof(WNDCLASSEX));
 hThisInstance = hInstance;
 LoadLibrary("Riched20.dll");

 wc.cbSize = sizeof(WNDCLASSEX);
 wc.style = CS_HREDRAW | CS_VREDRAW;
 wc.lpfnWndProc = WindowProc;
 wc.hInstance = hInstance;
 wc.lpszMenuName = MAKEINTRESOURCE(IDR_MYMENU);
 if(!(wc.hIcon = LoadIcon(hInstance,MAKEINTRESOURCE(IDI_MYICON)))) {
  HRESULT res = GetLastError();

 }
 wc.hCursor = LoadCursor(NULL, IDC_ARROW);
 wc.hbrBackground = (HBRUSH)COLOR_WINDOW;
 wc.lpszClassName = TEXT("Testcpp");
 RegisterClassEx(&wc);

 hWnd = CreateWindowEx(NULL, 
       wc.lpszClassName,
       TEXT("uTest"),
       WS_OVERLAPPEDWINDOW,
       300,
       200,
       450,
       300,
       NULL,
       NULL,
       hInstance,
       NULL);
 ShowWindow(hWnd,nCmdShow);

 MSG msg;
 while (GetMessage(&msg, NULL,0,0)) {
  TranslateMessage(&msg);
  DispatchMessage(&msg);

 }


 return msg.wParam;
}

According to MSDN, WM_PAINT is only called automatically after either UpdateWindow() or ReDrawWindow(), or when you SendMessage with it as message. I do none, however. I basically only want to call WM_PAINT after a user interaction, not before... is there any way to fix this? What is causing this? (I guess its some bizare side-effect I cant find documentation for >.<)

If you're trying to keep the window from painting until you get a specific command, make the window invisible and change it to visible in the command handler. — Mark Ransom, Dec 22 '10 at 21:22

Joe White · Accepted Answer · 2010-12-22T21:28:25.490

6

WM_PAINT is called any time your window needs to be redrawn. That's what it's for. Showing the window, resizing the window, restoring the window from minimized state, bringing the window to the front after it's been covered by another window, minimizing another app that was covering up your window... these are just a few of the things that will send a WM_PAINT.

I think you're trying to use WM_PAINT for something it's not intended for.

edited Dec 22 '10 at 21:28

answered Dec 22 '10 at 21:18

Joe White

94,807
60
220
330

You forgot creating the window. – Mark Ransom Dec 22 '10 at 21:22
@Mark, I didn't think the window got a WM_PAINT until it was actually shown. Just creating it wouldn't send a paint message, would it? – Joe White Dec 22 '10 at 21:27
you're absolutely correct. But the OP might not realize that the sequence (create window, show window) are tightly coupled. – Mark Ransom Dec 22 '10 at 21:40
Should I slap the textout-generation bit to some other message then? – KaiserJohaan Dec 22 '10 at 22:33
@KaiserJohaan, the TextOut is in exactly the proper place. You've never really told us what you think is wrong. – Mark Ransom Dec 23 '10 at 02:23

score 3 · Answer 2 · answered Dec 23 '10 at 02:18

3

What is causing this?

My guess is that when the user selects the menu item from the menu, the act of displaying the menu has covered part of the client window.

So when the menu is finally remove, a *WM_PAINT* message is generated to recreated that missing portion of the client window.

answered Dec 23 '10 at 02:18

mrsheen

882
8
10

And that kind of behaviour is O/S-dependent, e.g. it doesn't happen when Aero effects are enabled (because the O/S has cached that portion of the window and so can redraw it without the application's help). – ChrisW Dec 23 '10 at 10:08

score 2 · Answer 3 · answered Dec 22 '10 at 21:28

According to MSDN, WM_PAINT is only called automatically after either UpdateWindow() or ReDrawWindow(), or when you SendMessage with it as message.

It's more complicated than that. WM_PAINT might be generated almost any time; for example see also Synchronous and Asynchronous Drawing.

I don't think you can prevent a WM_PAINT. You can:

Force an immediate WM_PAINT (e.g. by calling Update)
Try to combine/delay several paints into one (e.g. by using several calls to InvalidateRect)

Instead of preventing WM_PAINT, you should concentrate on avoiding/fixing whatever "side effect" you say you're getting when WM_PAINT is processed.

win32: WM_PAINT calls but not supposed to be!

3 Answers3