Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!ruuinf!jeroen
From: jeroen@ruuinf.cs.ruu.nl (Jeroen Fokker)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Closing AES boxes interfering with VDI drawing
Keywords: redraw timing
Message-ID: <4533@ruuinf.cs.ruu.nl>
Date: 18 Dec 90 09:19:59 GMT
References: <9267@ncar.ucar.edu> <1990Nov29.145734.1059@chinet.chi.il.us> <27569349.8114@maccs.dcss.mcmaster.ca> <111330@convex.convex.com>
Organization: Utrecht University, Dept. of CS
Lines: 59

In article <111330@convex.convex.com> rosenkra@convex.com (William Rosencranz) writes:

> [ to draw a dialog ]
>
> 1. Build the dialog box via a RCS-like prog or by hand
> 2. Center it on the screen with form_center() [ or if you want to, fill in
>    the x,y,w,h fields in the structure manually ]
> 3. Call form_dial( FMD_START, ... ) to reserve some screen space
> 4. Call form_dial( FMD_GROW, ... ) to draw a growing box [ optional ]
> 5. Call objc_draw( ) to actually draw it on the screen
> 6. Call form_do( ) to let the AES handle the dialog.  
> 7. When you get control back again, call form_dial( FMD_SHRINK, ... )
> 8. Call form_dial( FMD_FINISH, ... ) to free up screen space

> this is the "normal" way of doing it, but it does have limitations. i think
> the max dialog size is 1/4 the screen as that is all the memory form_dial
> deals with. i may be wrong here, though...

The call to form_dial(FMD_START...) does not reserve ANY memory.
It just remembers the coordinates of the rectangle that will be disturbed.

The final call to form_dial(FMD_FINISH...) likewise doesn't restore
the screen. Rather, it generates an "event".
This event must be picked up by the program by a call to
evnt_multi. The infamous coordinates are supplied to you by the event,
and it is the responsibility of the program to redraw the
affected screen.

The limitation of 1/4 the screen size applies only to form_alert
dialogues. The background of form_alert dialogues is saved
by the operating system, and therefore no events are generated
by this call.


> there is a better way, at least i use it:
> 1) as above
> 2) save ALL the screen to a 32000 byte buffer
> 3) objc_draw anywhere u like
> 4) form_do as above, in a loop while (!exit_condition)
> 5) on exit, restore the entire screen from the buffer

I prefer this solution, too.
You can even have sub-dialogues by allocationg a second buffer.

>you don't get the (silly?) growbox/shrink box (my beta testers told me to
>ax them on some code i produced a while back).

The choice to grow/shrink box is independent of the way
you save the background.
This feature is achieved by the  form_dial(FMD_GROW/SHRINK) calls,
which can be included or not, regardless of the way you
subsequently restore the screen.

Ideally, the grow/shrink is executed conditionally depending
on a switch that can be set by some preferences-dialogue.
--
Jeroen Fokker                                 |  jeroen@cs.ruu.nl
dept.of Computer Science, Utrecht University  |  tel.+31-30-534129
PObox 80089, 3508TB Utrecht, the Netherlands  |  fax.+31-30-513791