XBR4D76H@DDATHD21.BITNET (08/05/87)
I discovered a strange bug in the AES window manager which can be triggered
by following procedure:
1. start a GEM application which opens a window
2. activate an accessory which opens another window
(i.e. Control Panel, Calculator, etc.)
3. exit GEM application without closing the accessory window
Now repeat (1) and (2) and watch what happens to the windows if you move
one of them.
The effects vary from mispositioned window border elements to missing
redraws of the work areas.
Once triggered the bug seems to stay resident until reboot.
The ST is like a sort of "magic hat":
You'll never know what bug is going to jump out next.
Konrad A. Hahn
BITNET: XBR4D76H@DDATHD21rowley@AMES-NAS.ARPA (Karl Rowley) (08/05/87)
In article <8708050514.AA11588@ucbvax.Berkeley.EDU> XBR4D76H@DDATHD21 (Konrad Hahn) writes: >I discovered a strange bug in the AES window manager which can be triggered >by following procedure: ... >The effects vary from mispositioned window border elements to missing >redraws of the work areas. 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"? Karl Rowley rowley@ames-nas.arpa
burris@ihuxz.ATT.COM (Burris) (08/06/87)
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
rowley@ORVILLE.ARPA (Karl Rowley) (08/06/87)
In article <2233@ihuxz.ATT.COM> burris@ihuxz.ATT.COM (Burris) writes: > >Do you know if the applications you are running are using the wind_update() >routine before doing any drawing inside a window? Yes, I have seen this problem when the application and desk accessories running (which I had written) were all using wind_update correctly. The problem I was referring to is not that windows get trashed when they are updated. The problem is with windows that the screen manager thinks still exist, but should not exist. If you have the Mark Williams C package, you can recreate the problem as follows: 1) Run the msh shell. 2) From msh start GEM kermit (or another GEM program that lets you use desk accessories). 3) Open the Control Panel from inside of kermit. 4) Exit kermit without closing the Control Panel. 5) Run kermit again from msh. 6) Open the Control Panel again. Move it all around the screen. Notice how the screen manager still thinks there is a second window titled "Control Panel"? The second window is never redrawn, but fills up with garbage as the other window is moved around over it. If steps 4, 5, and 6 are repeated again a number of times, there will eventually be no window handles left and the Control Panel will not open when selected. 7) Go back to the desktop. Repeat steps 3-6 running kermit from the desktop. Everything looks fine. My conclusion: the GEM desktop is doing something to close/clean up desk accessories/windows between running applications. The msh shell must not. Does anyone know how the desktop does this? Karl Rowley rowley@ames-nas.arpa
hakanson@orstcs.cs.ORST.EDU (08/09/87)
<yum!>
Regarding AES bugs, using GEM applications under the MWC shell, etc.,
I just happened across the following information in the release notes
of MWC 2.0. It mentions that some applications depend on the desktop
to clean up after them instead of doing it themselves. They go on to
say that these programs may crash upon exiting back to the shell.
Also, they mention that 1st Word, Atari BASIC, and Atari Logo are such
programs.
Marion Hakanson CSnet: hakanson%oregon-state@relay.cs.net
UUCP : {hp-pcd,tektronix}!orstcs!hakanson