Re: a new drawing not erase previous drawing?
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Mon, 06 Jun 2005 21:53:24 -0400
There are several answers here...
On Mon, 6 Jun 2005 22:50:48 +0300, "Andra" <andraatlatnetdotlv> wrote:
>visual studio c++ 6.0, mfc, graphics
>
>
>
>in my program a new drawing erases previous drawing. How to manage that all
>that is drawn stays alive on the window? And is not erased when the window
>is covered by another window, as well. And that the image does not
>flicker...
****
Frequently, when you invalidate a window, the default is "TRUE", meaning to erase the
background. The OnEraseBkgnd handler is called, and the default, if you don't override it,
is to simply draw a blank area using the default background color for the window class
(usually white).
To avoid this, you can override OnEraseBkgnd and do nothing, and not call the superclass,
BUT...and here's the catch...you are now responsible in the OnPaint handler to paint any
part of the window that you do not want to remain in whatever bogus state it was left in.
The problem with OnPaint is that you have no idea why it is called; you could have had a
dialog box, including a dialog box from another app, have popped up on top of it, thus
trashing its contents. Or some other window might have partially covered it. Who knows?
You certainly don't. Therefore, you must redraw ALL of the invalidated area, without
exception, every single pixel, or you will end up with trash on the screen.
Flicker avoidance is a more serious problem. For example, the simplest way to avoid it is
to draw the entire image in an offscreen bitmap and BitBlt it onto your drawing surface.
The effect to the user is that if nothing changes, no visible change is seen. If only part
of the drawing had been obscured, the drawing area is clipped so only that part is redrawn
anyway. There can be performance implications with this technique, but unless you know
performance is a problem, you can safely ignore them (and if it IS a problem, you might
end up spending a lot of effort to reduce the problem! The simplest method, by the way, is
to create a clipping region for your bitmap which is identical to the clipping region of
your window).
****
>
>
>
>Those last two have from time to time appeared in my attempts to solve the
>first problem. And that I didn't manage at all - make the first drawing,
>then the second, see them both at the same time on the window.
****
Be careful about this idea. There is no "first" or "second" drawing. There is only the
window image, and you have to be prepared to draw any or all of it, at any time, without
warning. While logically there is a "first" and "second" drawing, where the "second" is
what appears on top of the "first", you should expect to have to draw both, in that order,
at any time. You cannot assume that any pixel, once placed in the window, will remain
intact. On the contrary, you MUST assume that any pixel can be trashed at an time for any
reason, and you have no control of this. Your responsibility is to see that the pixels can
be re-created on demand.
****
>
>
>
>I have tried the following and maybe more: Invalidate(false),
>InvalidateRect(false), override OnEraseBkgnd, SendMessage(WM_PAINT, 0, 0),
>RedrawWindow(NULL, NULL,RDW_NOERASE), DefWindowProc(WM_PAINT,
>(WPARAM)dc.m_hDC, 0).
****
Invalidate(FALSE) and InvalidateRect(FALSE) would be one solution, but remember, the
system is free at any time to do Invalidate(TRUE) or InvalidateRect(..., TRUE), and you
can't control that. Assume it will happen.
Sending WM_PAINT is not only useless, it is harmful. Under no circumstances, ever, is it
possible to issue such a SendMessage or call DefWindowProc as you show. WM_PAINT messages
are special and can ONLY be generated by the operating system (for example, prior to
sending the message, it has prepared a clipping region for BeginPaint to work on. You
cannot do this yourself; only the system can do this). RedrawWindow will have no effect. I
think you have missed the key Windows paradigm here: any pixel can be erased at any time
for any reason by means you cannot control, and you, and you alone, have complete
responsibility to see that such pixels are correctly redrawn. There is no way to put
pixels on a window and expect they will stay there. They will not. Windows *guarantees*
they will not.
*****
>
>
>
>please help!
>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- a new drawing not erase previous drawing?
- From: Andra
- a new drawing not erase previous drawing?
- Prev by Date: How to disable "Ctrl"+"Alt"+"Del" and start menu in XP PROF?
- Next by Date: Re: CEdits and CStrings
- Previous by thread: Re: a new drawing not erase previous drawing?
- Next by thread: Re: a new drawing not erase previous drawing?
- Index(es):
Relevant Pages
|
