Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!microsoft!chrisg
From: chrisg@microsoft.UUCP (Chris GUZAK)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Does a window know when it is being overwritten?
Message-ID: <72275@microsoft.UUCP>
Date: 11 May 91 03:42:56 GMT
References: <59847@siemens.siemens.com> <19209@bunker.isc-br.com>
Reply-To: chrisg@microsoft.UUCP (Chris GUZAK)
Organization: Microsoft Corp., Redmond WA
Lines: 29

All windows apps must be able to regenerate their display
at any time.  You must have an internal representation of
you data that you can use to regenerate your display.  
(ie, you can't save your state on the display device)

If you design your program assuming you can take things off the
display it will not work.  It will appear to work for a while,
but when you get in low memory conditions it will fail (windows
won't restore what is under popups, etc, it will ask you to
regenerate it).

In general, there is no way to know if you are covered up
(especially in future versions).

Chris

In article <19209@bunker.isc-br.com> shap@clunker.UUCP (Joseph D. Shapiro) writes:
>In article <59847@siemens.siemens.com> jrv@demon.siemens.com writes:
>: Does a window know when it is being overwritten?  The potential exists
>: whenever the input focus is lost.  The focus will be lost whenever another
>: application is brought up on top of my client area.  This is also true when
>: my application brings up a dialog box.  For drop down menus and child windows
>: I don't think that is true.  I have control over when the child window will
>: appear.  I don't recall any message sent just before a menu is dropped.  The
>: basic problem is that before anyone overwrites part of my client display
>: memory, I have to save the pixels which will be overwritten.  I don't have
>: another copy of the pixel data.  It has been generated by a coprocessor on
>: the display card running some algorithms on my image data.  I could keep a
>