Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!uwvax!oddjob!gargoyle!ihnp4!ihuxz!burris
From: burris@ihuxz.ATT.COM (Burris)
Newsgroups: comp.sys.atari.st
Subject: Re: AES bug
Message-ID: <2233@ihuxz.ATT.COM>
Date: Thu, 6-Aug-87 08:30:18 EDT
Article-I.D.: ihuxz.2233
Posted: Thu Aug  6 08:30:18 1987
Date-Received: Sat, 8-Aug-87 11:09:41 EDT
References: <8708051539.AA09963@ames-nas.arpa>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 51
Summary: Are you using wind_update()?

In article <8708051539.AA09963@ames-nas.arpa>, rowley@AMES-NAS.ARPA.UUCP writes:
> I have only noticed this problem when GEM applications are started from 
> the Mark Williams msh.  It doesn't seem to happen when the applications are
> started with the GEM desktop.  The desktop must be doing something to 
> "clean up" between the running of applications.  
> 
> Does anyone know how to avoid these "ghost windows"?  
> 
> 

Do you know if the applications you are running are using the wind_update()
routine before doing any drawing inside a window?

I had a problem similar to this while working on a MIDI application. The
problem was caused when a window was either sized or moved. When either of
these occur message is sent to the application to redraw the window. Before
the redraw operation the wind_update( BEG_UPDATE ) call should be performed
to freeze the screens update rectangle list.

I don't have the code in front of me but I think the sequence is something
like:

1. Window is sized or moved.
2. Application recieves size or move message.
3. Application issues a size or move command.
4. AES determines if any of the window contents for any visible windows need
   to be redrawn.
5. The application recieves a window redraw message.
6. The application calls wind_update( BEG_UPDATE ) to freeze the screens
   rectangle list.
7. The application steps through the rectangle list redrawing each rectangle
   until there are no more on the list.
8. The application calls wind_update( END_UPDATE ) to allow updates to the
   list.

If the above sequence is used, the only quirks I have seen using Mark Williams'
shell is that the AES thinks the desktop behind the windows is the color of the
desktop before executing msh. This means that as windows are sized, moved, or
closed the background could be a different color (and probably is).

For instance, in medium resolution mode I have the colors black, white, red,
and green. The desktop is green. When I execute msh I have a black background
with white letters. When I execute a multiple window application and close one
of the windows the background that was behind the window is green and the rest 
of the screen is black.

This could probably be fixed easily but I haven't spent a lot of time on it
since my application is more important.

Dave Burris
ihnp4!ihuxz!burris