Hello.

I've started using D5.01Pro on Win2KPro SP2 and have encountered an
unexpected form repaint problem. If I create a basic application
consisting of a single form and no other controls/components then I
observe that the form is not repainted correctly when another
form/window is moved over the top of it. For instance, if I open NOTEPAD
and slowly move it over the basic form then white rectangular areas are
left scattered over the form. If I then select the form the white areas
remain even during form movement and maximize/restore. Minimizing the
form or moving out of the screen area cause it to be repainted
correctly. If controls are placed on the form then they are always
repainted correctly but the form area between them is corrupted as just
described. I put a status bar on the form and updated it in the
Form.OnPaint event to show that repaints are occuring and they are but
the form remains corrupt. It's as though the corrupted areas have become
part of the form.

Other non-Delphi applications do not exhibit this behaviour although I
have noticed it sometimes occurs in the main menu bar at the top of
these windows. However, as soon as focus returns to the application the
main menu is redrawn correctly. I have not noticed the repaint problem
in the client area of non-Delphi applications.

This same Delphi application on Win95/98 (different machine) does not
exhibit the problem.

I have upgraded my display drivers to the latest level but this did not
help. I doubt the drivers are the problem because, as I have said,
non-Delphi applications do not exhibit this bahaviour.

Is there something about Delphi forms in W2K that prevent a "full"
repaint from occuring?

Any help would be appreciated.

IBM Thinkpad I1300
Lynx EM+ 4M video
Win2K Pro SP2
Delphi 5.01 Pro

TIA

Richard Walton.

I use D5 with Win2k SP2, and I have no problems.  Sounds a bit like a Video Card
problem. Or not enough memory, etc.

Regards,
-Steve-

news:3BB09551.27CF1D5C@au1.ibm.comREMOVE...
Hello.

I've started using D5.01Pro on Win2KPro SP2 and have encountered an
unexpected form repaint problem.

It may also be the number of colors set - make sure it's more than 16
colors.  Try to get to 16 bit as 256 color mode will palletize the display
and make it look slightly funny for background apps.

Eric

Thanks Eric. I am running at 1024x768 with 24bit color. Video card has 4M and
system 256M. The problem occurs at all resolutions and color depths.

Richard.

Thanks Steve. I am running at 1024x768 with 24bit color. Video card has 4M and
system 256M. The problem occurs at all resolutions and color depths.

4 meg is a little slim.  I'm running 32 with video on this system.  My previous
system had 16.

What size monitor?  I did have trouble a while back with a 4meg card and 19"
monitor.  It was one of the reasons I upgraded my system.

Regards,
-Steve-

news:3BB10FF0.CDCB8A3A@au1.ibm.comREMOVE...
Thanks Steve. I am running at 1024x768 with 24bit color. Video card has 4M and
system 256M. The problem occurs at all resolutions and color depths.

IIRC, the repaint logic is so intelligent that it only updates the parts
which are needed to be updated... Try a "Form1.Invalidate;" in a button or
so.

For your problem I would suggest an update of your graphic board also ...

Helge.

Thanks Helge, using the button worked. I then added an Application.OnActivate
event which simply contained the Invalidate call. This also worked. The
corruption still appeared on the inactive form but all was repainted correctly
when it gained focus. Any idea why the repaint is not occuring automatically?

I would definitely like to upgrade the video hardware but I am using a work
supplied laptop. Thanks again.

Richard.

Steve, I am using a work supplied laptop (Thinkpad). I would like to upgrade the
video hardware but am not in a position to do so. I run Delphi applications on a
Pentium 166 with a 2M video card and 19" monitor (Win95) and do not see this
problem at all.

I have found that by adding an Application.OnActivate event which simply calls
Invalidate causes a complete repaint to occur when focus returns to the form. The
corruption still occurs but is repaired correctly. Not sure why activating the
application doesn't automatically cause the repaint to occur.

Richard.

It's not a bug - it's a feature... IIRC windows only remembers the area
under a form and paints that area again when it comes into the foreground
...

Just another thought: What about calling Invalidate in OnPaint? Maybe you
aren't allowed to (infinitive loop???) but you could give it a try until
someone calls me stupid here...

Helge.

I did try Invalidate in OnPaint and an infinite loop was indeed the result.
It seems strange that Paint messages are being received by the form when the
window is being moved over the top of it but corruption still occurs. It's
almost as if a timing issue is causing the repaint before the overlying
window has completed its move. Could be a video card problem.

I agree that repainting only the necessary parts of a form is a good feature.

Richard.