WM_PAINT and WM_ERASEBKGND
-
In general the
WM_PAINThandler will not "touch" every pixel: it might just write some text in the corner for example. Still the entire client area need to be updated if its dirty. Thus the two stage painting.Steve
-
In general the
WM_PAINThandler will not "touch" every pixel: it might just write some text in the corner for example. Still the entire client area need to be updated if its dirty. Thus the two stage painting.Steve
OK... that i know. But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary? And i could find out that if a WM_ERASEBKGND message is sent, WM_PAINT will be surely sent after that to update the whole area. So i think there is no need to process WM_ERASEBKGND to draw anything.
- NS -
-
OK... that i know. But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary? And i could find out that if a WM_ERASEBKGND message is sent, WM_PAINT will be surely sent after that to update the whole area. So i think there is no need to process WM_ERASEBKGND to draw anything.
- NS -
NS17 wrote:
But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary
It depends. If your
WM_PAINThandler paints every dirty pixel then you don't needWM_ERASEBKGND. If, as is generally the case, theWM_PAINThandler only touches a subset of the dirty pixels then without theWM_ERASEBKGNDhandler the dirty pixels not painted will still be dirty. It depends on your application. You can handle theWM_ERASEBKGNDmessage and return 0 to stop the erasing if you want to.Steve
-
NS17 wrote:
But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary
It depends. If your
WM_PAINThandler paints every dirty pixel then you don't needWM_ERASEBKGND. If, as is generally the case, theWM_PAINThandler only touches a subset of the dirty pixels then without theWM_ERASEBKGNDhandler the dirty pixels not painted will still be dirty. It depends on your application. You can handle theWM_ERASEBKGNDmessage and return 0 to stop the erasing if you want to.Steve
-
Stephen Hewitt wrote:
as is generally the case, the WM_PAINT handler only touches a subset of the dirty pixels then without the WM_ERASEBKGND handler the dirty pixels not painted will still be dirty
Could you please explain a little more?
- NS -
The WM_PAINT does not always paint the whole of the DC, it is passed an 'update region' which is a series of 'dirty' rectangles. Lets say you drag a button around on your window. The rectangle for the new position is passed to WM_PAINT, without the WM_ERASEBKGND The rectangle of the old position would not be filled in, causing a trail effect. The button will only paint within it's own bounds ( the first rectangle ) since it knows nothing of lies beneath it. In most cases WM_ERASEBKGND is not required, but if there is anythig on your main window that changes appearance ( uncovering pixels beneath it ) then this message will fill in those pixels giving WM_PAINT a fresh canvas. There are a few class styles that also effect the painting of a window, CS_VREDRAW, CS_HREDRAW, CS_CLIPCHILDREN, CS_CLIPSIBLINGS to name a few...
-
The WM_PAINT does not always paint the whole of the DC, it is passed an 'update region' which is a series of 'dirty' rectangles. Lets say you drag a button around on your window. The rectangle for the new position is passed to WM_PAINT, without the WM_ERASEBKGND The rectangle of the old position would not be filled in, causing a trail effect. The button will only paint within it's own bounds ( the first rectangle ) since it knows nothing of lies beneath it. In most cases WM_ERASEBKGND is not required, but if there is anythig on your main window that changes appearance ( uncovering pixels beneath it ) then this message will fill in those pixels giving WM_PAINT a fresh canvas. There are a few class styles that also effect the painting of a window, CS_VREDRAW, CS_HREDRAW, CS_CLIPCHILDREN, CS_CLIPSIBLINGS to name a few...
-
WalderMort wrote:
The rectangle for the new position is passed to WM_PAINT, without the WM_ERASEBKGND
...but from Spy++ tool I found that WM_ERASEBKGND is also coming while dragging a message box over a window (I used notepad).
- NS -
Just like with my example using your window and a button, the desktop is itself a window, when you move a window over yours, those pixels are erased, the desktop is telling your window that it is now uncovered and should fill in those uncovered areas.
-
NS17 wrote:
But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary
It depends. If your
WM_PAINThandler paints every dirty pixel then you don't needWM_ERASEBKGND. If, as is generally the case, theWM_PAINThandler only touches a subset of the dirty pixels then without theWM_ERASEBKGNDhandler the dirty pixels not painted will still be dirty. It depends on your application. You can handle theWM_ERASEBKGNDmessage and return 0 to stop the erasing if you want to.Steve
Can anyone show a condition when WM_PAINT is sent but WM_ERASEBKGND is not? or when WM_ERASEBKGND is sent but WM_PAINT is not?
-
Can anyone show a condition when WM_PAINT is sent but WM_ERASEBKGND is not? or when WM_ERASEBKGND is sent but WM_PAINT is not?
If you use InvalidateRect(...,..., false) then only WM_PAINT is sent. If you use InvalidateRect(...,..., true) then WM_PAINT is called and when you use 'BeginPaint' inside WM_PAINT it calls WM_ERASEBKGND (when WM_ERASEBKGND is called, the Invalid rectangle is nullified). In a normal circumstance the Invalidate rectangles received in WM_ERASEBKGND and WM_PAINT are same.
-
OK... that i know. But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary? And i could find out that if a WM_ERASEBKGND message is sent, WM_PAINT will be surely sent after that to update the whole area. So i think there is no need to process WM_ERASEBKGND to draw anything.
- NS -
Whether it is background or foreground you draw on same DC. This is only an option given to you to separate background and foreground. The usefulness comes when 'InvalidateRect' etc. are called in the program. Normally, WM_ERASEBKGND and WM_PAINT both get called ('resize' say). If you use InvalidateRect(...,...,false) only WM_PAINT gets called. If you use InvalidateRect(...,...,true) then WM_ERASEBKGND gets called when you use 'BeginPaint' inside WM_PAINT.
-
Whether it is background or foreground you draw on same DC. This is only an option given to you to separate background and foreground. The usefulness comes when 'InvalidateRect' etc. are called in the program. Normally, WM_ERASEBKGND and WM_PAINT both get called ('resize' say). If you use InvalidateRect(...,...,false) only WM_PAINT gets called. If you use InvalidateRect(...,...,true) then WM_ERASEBKGND gets called when you use 'BeginPaint' inside WM_PAINT.
-
Can anyone show a condition when WM_PAINT is sent but WM_ERASEBKGND is not? or when WM_ERASEBKGND is sent but WM_PAINT is not?
Hi I think this is depend on how the window be update. When you call Invalidate(...), you can specify the erase background occuer or no. I think when you want to update only an item in the window like a button in the toolbar NOT all window area, WM_ERASEBKGND is not needed because not change made in other places of the window. Kind Regards. mrjavadtaheri@gmail.com