WM_PAINT call confusion

My understanding is as follows:

When a window needs painting, the procedure calls WM_PAINT. If there is no handler for this message, the message is passed to DefWindowProc which takes care of the default painting of the window.

Code:

---

LRESULT CALLBACK
WndProc(HWND hwnd,
        UINT msg,
        WPARAM wParam,
        LPARAM lParam)
{
    switch(msg)
    {
        ...

        default:
            return DefWindowProc(hwnd, msg, wParam, lParam);
    }
    return 0;
}

---

When a handler is present, it intercepts the message and executes the code within the handler. Then, instead of calling DefWindowProc, the window procedure then returns 0

Code:

---

LRESULT CALLBACK
WndProc(HWND hwnd,
        UINT msg,
        WPARAM wParam,
        LPARAM lParam)
{
    switch(msg)
    {
        case WM_PAINT:
        {
            HDC hdc;
            PAINTSTRUCT ps;

            hdc = BeginPaint(hwnd, &ps);
            ...
            EndPaint(hwnd, &ps);
        }
        break;

        default:
            return DefWindowProc(hwnd, msg, wParam, lParam);
    }
    return 0;
}

---

So my question is, if WM_PAINT is not being handed to DefWindowProc, when and how is the window actually drawn?

Um... I would say that when you call BeginPaint, Windows fills out the PAINTSTRUCT with meaty chunks of goodness, such as a DC for you to use and a RECT that describes the area to be redrawn (which Windows also validates or marks "clean" before handing to you). If the area is complex (i.e. not a rectangle) you'll receive more than one WM_PAINT to cover the difference.

So, you do your drawing after that and finish up with an EndPaint (which frees some resources used). WM_PAINT messages are considered with fairly low priority in Windows however, so in some (specific) cases you may want to pump the message yourself rather than letting USER32's dispatch mechanism deal with it.

Quote:

---

Originally Posted by eth0

My understanding is as follows:
...So my question is, if WM_PAINT is not being handed to DefWindowProc, when and how is the window actually drawn?

---

It appears that you are drawing it with the HDC you are given.

Quote:

---

Originally Posted by SMurf

...If the area is complex (i.e. not a rectangle) you'll receive more than one WM_PAINT to cover the difference.

---

I believe this is incorrect. I think WM_PAINT messages are combined as they add up in the message queue. This generates complex regions for the paint DC and does not need to generate several rectangle ones.

confirmed...

Quote:

---

...In addition, multiple WM_PAINT messages for the same window are combined into a single WM_PAINT message, consolidating all invalid parts of the client area into a single area. Combining WM_PAINT messages reduces the number of times a window must redraw the contents of its client area.

---

http://msdn.microsoft.com/library/de...sagequeues.asp

Yeah, but since the rc member of the PAINTSTRUCT is almost always used to paint with, this mean's that you'll be using the smallest RECT that bounds the complex area. You can get the actual region if you want, but that can only be used with certain functions (FillRgn for example).

I was only debating the "multiple WM_PAINT" part. No offense intended

Quote:

---

Originally Posted by SMurf

Yeah, but since the rc member of the PAINTSTRUCT is almost always used to paint with, this mean's that you'll be using the smallest RECT that bounds the complex area. You can get the actual region if you want, but that can only be used with certain functions (FillRgn for example).

---

Weather he uses the rcPaint member or the actual arbitrary region doesn't really matter because, windows will prevent you from painting outside the invalid region anyway.

To to OP: The window will only *not* be painted if you Handle the WM_PAINT message and sometimes also the WM_ERASEBKGND message and not do *any* painting at all or, erasing. Otherwise, the window will use the default implementation to paint and validate itself.

But to put it simply; the paining is done in the WM_PAINT handler if you intercept, or, handle it and do some painting.

Quote:

---

Originally Posted by xeddiex

Weather he uses the rcPaint member or the actual arbitrary region doesn't really matter because, windows will prevent you from painting outside the invalid region anyway.

To to OP: The window will only *not* be painted if you Handle the WM_PAINT message and sometimes also the WM_ERASEBKGND message and not do *any* painting at all or, erasing. Otherwise, the window will use the default implementation to paint and validate itself.

But to put it simply; the paining is done in the WM_PAINT handler if you intercept, or, handle it and do some painting.

---

I've subclassed a static and it seems that the window is not painting or erasing as you stated. If windows get moved over it the image of those windows will be moved onto the static. Do you know the solution to this?

Example: http://programming-designs.com/error.gif