Re: Win32Lib:repaint screen on move 2nd window
------=_NextPart_000_0007_01C01696.A2328820
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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.
------=_NextPart_000_0007_01C01696.A2328820
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>If I'm way off base, let me =
know...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I do not use the Win32Lib at all in my =
efforts to=20
write "windows" programs, but I</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>have run into the same exact problem =
myself. The=20
"copies" being left behind</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>is due to the WM_ERASEBKGND message not =
being=20
processed properly by the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>window that is overlapped. It may be =
that the=20
message is "NULL"ified somewhere.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>The thing about telling a window to =
repaint itself,=20
is that "windows" will do that</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>automatically by posting a WM_PAINT =
message to the=20
window. If it is not</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>processed properly, that will cause =
"windows" to=20
erase it (even if you have drawn</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>on it) again. If you intercept the =
WM_PAINT message=20
(I think that is what onPaint</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>does), you must "validate" the region =
that you drew=20
on.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I searched the copy of Win32Lib that I =
have, and it=20
does not call ValidateRect</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>anywhere that I could find. If onPaint =
is meant as=20
a routine that is run when a</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>window recieves the WM_PAINT message, =
then=20
ValidateRect MUST be called</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>before the routine returns control to =
"windows", or=20
"windows" will erase the area</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>again.</FONT></DIV>
------=_NextPart_000_0007_01C01696.A2328820--
|
Not Categorized, Please Help
|
|
