🚀 go-pugleaf

In article <4ldji6$1qh@loki.tor.hookup.net>,
Rajendra Singh <Rajendra_Singh@msn.com> wrote:
>This is the most appropriate newsgroup that I could think of to post
>this query, so please, if it's not totally appropriate for me to post
>it here, forgive me.
>
>I have an application which is written in C using curses running on
>HP/UX v9.07.  I create a window, display some information in the
>window, ask the user to press a key, then get rid of the window.  The
>problem I'm having is that when the window goes away so does the text
>that was below it, i. e. it wipes out what was on stdscr.  How can I
>prevent this from happening?
>
>To get rid of the window I'm calling:  werase(), wrefresh(), and
>delwin() in that order.

(Boy I'm still fuming over that $4.25/hr programming job ad! If I had my hands
on the necks of these Jones Internet Channel people in Englewood, CO. I'd crush
their vertebrae to a pulp)

Anyway, to your question:

First of all, it's quite system specific, since curses it not part of the C
language. So if you ask in perhaps a UNIX newsgroup, you might get more help.
You should probably join the community of ncurses developers and users, since
they are actively working with curses and ncurses. Much of the expertise in
this area is concentrated around the ncurses mailing list.

Secondly, it always helps if you post some code, as longs as it's not reams and
reams...

Now, that aside, the reason that the region below your window which you destroy
is not repainted is because curses is not a system for maintaining overlapping
windows. The discipline of repainting windows is up to your application.  There
is no automatic ``expose and repaint'' calculation.

First of all, calling werase() doesn't help you one bit here. There is no need
to erase a window before deleting it with delwin(). All that will do is write
spaces to the terminal on next update. What you want to do is simply destroy
the window (or just keep it around if you will need it later), and tell curses
to redraw the window below it, in this case stdscr. This normally means calling
refresh() (the same as wrefresh(stdscr)). Curses does not know that the window
has been obscured before, so before calling refresh() you have to mark the
window for an update operation. This is done using touchwin().

So, to force an update of the stdscr, do touchwin(stdscr) followed by
refresh(). This will cause it to paint over all the windows as though it came
to the ``foreground''.

If you are maintaining multiple windows in a ``stacking order'', you must keep
them inside your own queue. When you change the stacking order, you repaint
back to front using touchwin() and wnoutrefresh() for each window (this means:
update to the internal update buffer, but DON'T send updates to the physical
terminal, hence the ``nout'' in the name). When this completes, you call
doupdate(), which will compute the changes between what is currently in stdscr
and the new image in the update buffer, and it will transmit an optimized
refresh sequence to the terminal in ``one fell swoop''.  The effect is quite
impressive, considering what you are working with! For example, if you raise a
back window to the front, only the portion that was previously obscured will
typically be redrawn, even though you redrew all the windows internally. That's
because that's the only region that is different between what was on the screen
before and what is in the update buffer.

On the other hand, if you call wrefresh() on each window instead, you will see
the repaint taking place window by window, which takes time and looks pretty
gross.