Path: utzoo!utgpu!watserv1!watmath!att!linac!midway!gargoyle!chinet!saj
From: saj@chinet.chi.il.us (Stephen Jacobs)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Closing AES boxes interfering with VDI drawing
Summary: Asking for more info
Keywords: redraw timing
Message-ID: <1990Nov29.145734.1059@chinet.chi.il.us>
Date: 29 Nov 90 14:57:34 GMT
References: <9267@ncar.ucar.edu>
Organization: Chinet - Chicago Public Access UNIX
Lines: 34

In article <9267@ncar.ucar.edu> moses@hao.ucar.edu (Julie Moses) writes:
>
>
>    I have an annoying problem in a program I am writing. I open a 
>dialogue box then close the box and immediately afterwards do some 
>VDI drawing (automatically not by hand) onto screen. The problem is
>that the closing of the AES dialogue box does not finish before the VDI
>drawing begins and therefore the VDI drawing is also erased.
>    I have tried putting a delay by evnt_timer and by a long for()
>loop between closing the box and the VDI drawing. In each case the
>closing of the AES dialogue box is also delayed and it still erases
>the VDI drawing. Then I thought it might be my wind_updates but after
>changing them it did not solve the problem either.
>
I don't quite understand this.  If I take the phrase "immediately afterwards"
literally, it could mean that the screen isn't being redrawn before the VDI
drawing is done.  When I started with GEM, I was confused between alert
boxes (which are erased by having GEM save a copy of what used to be on that
part of the screen, and slap it back in when the alert is closed) and dialog
boxes (which have to be redrawn by the application).  Could that be the 
problem?

The working difference is in one case, there's an evnt_multi(), in which 
some event causes the dialog to be used, and when the dialog ends, it falls
through to the VDI stuff (WRONG).  In the other (RIGHT) case, when the 
dialog ends, it sets a flag and recycles through the evnt_multi()-controlled
loop.  Next time through, the flag causes the VDI drawing to happen.  Of 
course, the pending message that a redraw is needed must be handled first.
Am I too far off on what's going on here?  If the code already takes the
correct approach, maybe an evnt_timer(0L) is needed to resynchronize the
event handler before the VDI stuff.  Or maybe there's a need to wait for
a VBL before drawing.  What to try next depends on what's been tried already.

                                    Steve J.