1. Re: Win32Lib:repaint screen on move 2nd window
Jason,
I *think* I have solved my problem by using Wolfgang's "jump to" to execute
the second program, although I may have just run into a bug that I gotta
look into.
Off base or not, the info is appreciated. Thanks.
Dan Moyer
----- Original Message -----
From: "Jason Mirwald" <mirwalds at SWBELL.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, September 04, 2000 3:36 PM
Subject: Re: Win32Lib:repaint screen on move 2nd window
If I'm way off base, let me know...
I do not use the Win32Lib at all in my efforts to write "windows" programs,
but I
have run into the same exact problem myself. The "copies" being left behind
is due to the WM_ERASEBKGND message not being processed properly by the
window that is overlapped. It may be that the message is "NULL"ified
somewhere.
The thing about telling a window to repaint itself, is that "windows" will
do that
automatically by posting a WM_PAINT message to the window. If it is not
processed properly, that will cause "windows" to erase it (even if you have
drawn
on it) again. If you intercept the WM_PAINT message (I think that is what
onPaint
does), you must "validate" the region that you drew on.
I searched the copy of Win32Lib that I have, and it does not call
ValidateRect
anywhere that I could find. If onPaint is meant as a routine that is run
when a
window recieves the WM_PAINT message, then ValidateRect MUST be called
before the routine returns control to "windows", or "windows" will erase the
area
again.
