Getchar w/wout echo

Karl Denninger karl at ddsw1.UUCP
Sun Sep 18 00:58:39 AEST 1988


In article <10608 at ulysses.homer.nj.att.com> kpv at ulysses.homer.nj.att.com (Phong Vo[eww]) writes:
>Hi all. I've just been alerted by a friend to this discussion on curses.
>Following are a few comments on the posting from Terry Lambert......
.....

Question for you curses hackers:

Why is it that in a terminfo based implementation that the screen does not
redraw on a "refresh()" call if there are characters stacked by type-ahead?

I've seen this behavior on three different terminfo implementations, so I
assume it's something internal to the design.  The worst part about this
problem is that there is _no way_ to prevent the gagging of output.

I can understand the intent -- to allow type-ahead to be processed, since
you might be able to process faster than the output could be sent to the
terminal over a serial line.  But this behavior makes curses _useless_ for
some interactive applications, as anytime you get ahead of the system, the
output freezes until the machine catches up!

The immediate application is a multiuser game -- which should display the
screen contents after each move.  With termcap curses I get the desired 
behavior.  With terminfo it's unplayable, as the screen just _sits_ there
until type-ahead is exhausted.  Since the game regulates input by use of a
sleep() call (or nap() in those systems which have it), there is _often_
stacked type-ahead waiting.  The result?  You can't see what the @#$# you're
doing!

Is there a work-around for this problem, or a way (other than flushing the
input) to get the output to appear _now_ when I call refresh()?  I haven't
been able to find it.

--
Karl Denninger (ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910
Macro Computer Solutions, Inc.    "Quality solutions at a fair price"



More information about the Comp.lang.c mailing list