Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!pmafire!uudell!bigtex!texsun!letni!rwsys!spudge!johnm
From: johnm@spudge.UUCP (John Munsch)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Does a window know when it is being overwritten?
Message-ID: <28989@spudge.UUCP>
Date: 4 May 91 00:15:25 GMT
References: <59847@siemens.siemens.com>
Reply-To: johnm@spudge.UUCP (John Munsch)
Organization: Friends of Guru Bob
Lines: 25

In article <59847@siemens.siemens.com> jrv@demon.siemens.com writes:
>I could keep a
>shadow copy of the data in extra memory on the display card.  But I will
>still not know if it is OK for the display coprocessor to write the data to
>the diplay area if I don't know that I own all of the pixels in my client
>area.

This is exactly what I would suggest you do.  Write the data not to the
screen but to a data storage area of your own.  Windows does not consider
the screen to be a storage medium, as far as it is concerned you should
normally be able to regenerate any display that is worth displaying.

What you are leaving out of your consideration is that you normally do not
worry about other windows (either child or other programs) when you output
to your own window.  Output from primitives ranging all the way from 
SetPixel() (ugh...) to SetDIBitsToDevice() is going to clip itself so that
it will not overwrite child windows (provided the window you write to was
created with WS_CLIPCHILDREN) and will NEVER overwrite other windows that
just happen to be laying across part of it.  It simply is not a concern for
you.

I wrote a picture display program without ever having to consider how 
other programs windows might intersect mine and it works very well.

John Munsch