Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!sun-barr!newstop!texsun!texbell!uhnix1!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.std.c
Subject: Re: ReadKey like Function in C
Message-ID: <5851@ficc.uu.net>
Date: 23 Aug 89 15:51:38 GMT
References: <148@trigon.UUCP> <207600029@s.cs.uiuc.edu> <941@lakesys.UUCP> <9322@chinet.chi.il.us>
Distribution: usa
Organization: Xenix Support, FICC
Lines: 29

In article <9322@chinet.chi.il.us>, kdb@chinet.chi.il.us (Karl Botts) writes:
> into the world of terminals which has not been discussed in this
> discussion.  [details of the problems of function keys on ASCII terminals]

> But making a
> kbhit() routine that only returns keyboard bytes doesn't accomplish
> anything -- it leaves the programmer still with the same problem.

Well, that's a good explanation of a problem with routines like kbhit(),
but for many applications the problem can be ignored. For example, a
readch() or testch() routine may not be dealing with a keyboard at all.
Or the application may just want to get a yes/no response.

Also, even if you solve the problem of function keys you have the problem
of portable screen output. Fortunately this is a solved problem in UNIX
with Ken Arnold's "curses" library. Implementations of curses for MS-DOS
exist, as well. Coincidentally, this solution also provides ReadKey(),
and handles function keys with a timeout (as you described).

Curses makes a good addition to the semi-standard C toolbox.

Unfortunately, this is overkill for many applications, and completely
inappropriate for others, such as a file transfer program. Something
lower level is still desirable.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"The security biz is subtle, you have to pick your trade-offs carefully."   U
	-- Barry Shein