adr@quiche.cs.mcgill.ca (Alain DURAND) (11/02/90)
Hi,
I'm desesperatly looking for help with some low-level curses functions.
This is my problem: i'm using curses in a program that spawnl (fork, exec)
to another one that should also write on the same screen. But i do not
want the screen to be redrawn from scratch (as the second program is
short and called very ofen, the result is that the screen is flashing
all the time...). So i'm using some low-level curses functions known as:
scr_dump, scr_restore and scr_init. In the sun doc curses(3v), it's said
that i shall use endwin(); scr_dump() in the master pgm and initscr()
scr_init() in the slave one. i tried and failled. i tried with scr_restore,
it works, but i've to perform a refresh or a wnoutrefresh before, which means
that the screen is ereased before the scr_restore and i've a flash on
the screen...too bad.
i'd like to have some help from people that have used succesfully those
functions...
thanks a lot,
alain Durand,
ps: please reply by E-mail at: adr@quiche.cs.mcgill.carwhite@nusdecs.uucp (0257014-Robert White(140)) (11/03/90)
Hi,
This is from memory, but I think It will do to give you some hints...
As I recall, the data provided in the implementation refrence was
misleading (I am being kind here). The correct thing to do is the
following:
ednwin("filename");
scr_dump("filename");
/* Exec into the following code */
initscr();
scr_init("filename");
overwrite(curscr,stdscr);
wnoutrefresh(stdscr);
/* Local Windowing Stuff */
endwin();
scr_dump("filename");
exit(??);
/* Back to Execing Program Here */
initscr();
scr_init("filename");
/* Continue from here as normal */
More or less at this point you will be asking yourself "why?"
The logic is twisted, but basic to the curses program. If you read
the definition of scr_init you will find that it says something like
(Quote from my manual follows) "The contents of filename are read in
and used to initalize the curses data structures about what the
terminal currently has on it's screen. ... curses will base it's next
update of the screen on this information rather than clearing the
screen and starting from scratch." In plain english curscr is set to
contain the information about the screen's current state, nothing
more.
The problem comes from the fact that this does nothing about the
contents of stdscr or any other window structure. Right after initscr
is called stdscr represents an ALL BLANK screen. Normally you need to
place and hide windows, for which you also need to maintain the
background, but the stdscrn structure you use for this IS BLANK. The
first time you use stdscr, your nice screen image goes the way of the
dodo. Since many of use automatically update stdscr by habbit (or
implicitly using refresh()) all that work for preservation apears to
do no good.
The overwrite call is used to preserve the current screen settings
into stdscr to allow for "real(tm)" use in the new program. The
sequence would read english-like as "Setup to do curses stuff, knowing
that the screen currently looks like 'filename' and, by the way, I
will be using that picture so lets save it as a good standard screen."
In this usage the screen from the parent prog is just wallpaper, but
that is all you really need it to be.
scr_restore is not acceptable for this usage because it tells curses
that "the screen is undefined but I want it to look like 'filename' so
clear off whatever garbage is there and put up that instead" This
causes the "flash".
The symetric scr_dump->initscr->scr_init sequence without the
overwrite just makes the return as flicker-free as the entrance. you
don't overwrite because the original stdscr already contains what you
need it to have. Doing the proper stack of wnoutrefreshes followed by
a doupdate will nicely wipe away the windows the child added to the image.
OTHER NOTES: you should do all the same slk_init and rippoffline(s)
in the child program you did in the parent program (if any) and then
use copywin to trim curscr into the line-windows and reduced-size
stdscr if you are using those techniques. (slk_init may call some of
the listed "illegal" calls, as may your rippoffline initalizers so be
wary durring this). If you arn't careful you can get some bizzare
results.
Rob.rwhite@nusdecs.uucp (0257014-Robert White(140)) (11/05/90)
Sorry to followup my own posting. endwin() does not take an argument... And I know it. I whas in a hury. ;-) Rob.