WM_PAINT, WM_ERASEBACKGROUND, etc
Brian Terry -- bterry@kartoffelsoft.com
Tuesday, December 03, 1996
Environment: VC++ 4.0, Win 95
Problem:
I'm confused by the difference between WM_PAINT and WM_ERASEBACKGROUND,
when they get called, and what resources are available at the time.
For example, if a window has the WS_CLIPCHILDREN property set and one
if it's children becomes visible, does the window receive a
WM_ERASEBACKGROUND message, or does the child? Why? Can I detect this
from within my OnEraseBackground handler?
I would appreciate any helpful resources or advice on this subject, as
I am quite confused.
Thanks in advance,
-brian
bterry@kartoffelsoft.com
Jim Lawson Williams -- jimlw@mail.ccur.com.au
Saturday, December 07, 1996
At 08:53 PM 3/12/96 -0800, you wrote:
>Environment: VC++ 4.0, Win 95
>
>Problem:
>I'm confused by the difference between WM_PAINT and WM_ERASEBACKGROUND,
>when they get called, and what resources are available at the time.
>
>For example, if a window has the WS_CLIPCHILDREN property set and one
>if it's children becomes visible, does the window receive a
>WM_ERASEBACKGROUND message, or does the child? Why? Can I detect this
>from within my OnEraseBackground handler?
>
>I would appreciate any helpful resources or advice on this subject, as
>I am quite confused.
>
>Thanks in advance,
>
>-brian
> bterry@kartoffelsoft.com
>
The message-dispatch sequence is WM_ERASEBACKGROUND followed by WM_PAINT. That is, "prepare the surface for painting, then do it!". The default CView paint-routine is below. Unless you need to fiddle with device-contexts, overriding OnDraw() is enough.
>From 4.2b Msdev\mfc\src\viewcore.cpp(181):
void CView::OnPaint()
{
// standard paint routine
CPaintDC dc(this);
OnPrepareDC(&dc);
OnDraw(&dc);
}
and D:\Msdev\mfc\src\WINFRM.CPP(2119):
BOOL CFrameWnd::OnEraseBkgnd(CDC* pDC)
{
if (m_pViewActive != NULL)
return TRUE; // active view will erase/paint itself
// for view-less frame just use the default background fill
return CWnd::OnEraseBkgnd(pDC);
}
>From "Books Online" CWnd::OnEraseBkgnd() --
An overridden OnEraseBkgnd should return nonzero in response to WM_ERASEBKGND if it processes the message and erases the background; this indicates that no further erasing is required. If it returns 0, the window will remain marked as needing to be erased. (Typically, this means that the fErase member of the PAINTSTRUCT structure will be TRUE.)
but best read the whole article. Look up "Command Routing", but a portion of the text is:
The general order in which a command target routes a command is:
1. To its currently active child command-target object.
2. To itself.
3. To other command targets [failing all else, the CWinApp object].
So, as far as OnEraseBkgnd() is concerned, the message will be passed-on from the frame to the view. Next, should such exist, the command should be routed to any descendents of the view.
OK, all o' that is fine, but maybe I'm not solving your real problem. What exactly is going wrong?
Regards,
Jim LW
>From the BBC's "Barchester Chronicles":
"I know that ultimately we are not supposed to understand.
But I also know that we must try."
-- the Reverend Septimus Harding, C++ programmer
Mike Blaszczak -- mikeblas@nwlink.com
Wednesday, December 11, 1996
At 12:33 12/7/96 +1100, Jim Lawson Williams wrote:
>but best read the whole article. Look up "Command Routing", but a portion
>of the text is:
>The general order in which a command target routes a command is:
> 1. To its currently active child command-target object.
> 2. To itself.
> 3. To other command targets [failing all else, the CWinApp object].
This is irrelevant.
>So, as far as OnEraseBkgnd() is concerned, the message will be passed-on
>from the frame to the view. Next, should such exist, the command should
>be routed to any descendents of the view.
No, that's not what happens. Command routing only applies to commands:
it only applies to WM_COMMAND messages and MFC's fake ON_UPDATE_COMMAND_UI
message-like mechanism. It applies to things that are like commands, too,
like IDispatch invocations.
But it doesn't apply to plain old messages like WM_ERASEBKGND. It just
wouldn't make sense: why would the whole frame window, for example,
erase its background just because an edit control in a CFormView didn't
handle WM_ERASEBKGND itself?
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
| Вернуться в корень Архива
|