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