Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Testing the keyboard buffer for MT/Not MT

Reply
Thread Tools

Testing the keyboard buffer for MT/Not MT

 
 
NaN
Guest
Posts: n/a
 
      05-02-2008
I've been trying to use _kbhit() but it didn't do what I thought it
would from books, "Detects whether a keypress is available for reading."

Herbert Schildt says,
"If the user has pressed a key, this function returns
true(non-0), but does not read the character.
If no keystroke is pending, kbhit() returns false (0)."

Here is the test code,

#include<conio.h>
void main(void) {
int ig1=0, ig2=0, ik=-1;
ig1 = _getch();
ik = _kbhit();
ig2 = _getch();
_getch();
printf("ig1=%d, ik=%d, ig2=%d", ig1,ik,ig2);
return;
}

Whatever keys I press a runtime, ik returned as 0. Where else would a
keystroke be "waiting" except in the buffer? If _kbhit() does not look
at the buffer, what does it look at?
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      05-02-2008
In article <fvg0rg$6tu$(E-Mail Removed)>, NaN <(E-Mail Removed)> wrote:
>I've been trying to use _kbhit() but it didn't do what I thought it
>would from books, "Detects whether a keypress is available for reading."


_kbhit() is not part of standard C. Please check a newsgroup
appropriate for your development environment if you wish to use it.

There is no method in standard C that can be used to detect
whether keypresses are available.
--
"Walter is a great man." -- Dennis Green
 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      05-03-2008
On May 2, 2:25*pm, NaN <(E-Mail Removed)> wrote:
> I've been trying to use _kbhit() but it didn't do what I thought it
> would from books, "Detects whether a keypress is available for reading."
>
> Herbert Schildt says,
> "If the user has pressed a key, this function returns
> true(non-0), but does not read the character.
> If no keystroke is pending, kbhit() returns false (0)."
>
> Here is the test code,
>
> #include<conio.h>
> void main(void) {
> * * * * *int ig1=0, ig2=0, ik=-1;
> * * * * *ig1 = _getch();
> * * * * *ik = _kbhit();
> * * * * *ig2 = _getch();
> * * * * *_getch();
> * * * * *printf("ig1=%d, ik=%d, ig2=%d", ig1,ik,ig2);
> * * * * *return;
>
> }
>
> Whatever keys I press a runtime, ik returned as 0. Where else would a
> keystroke be "waiting" except in the buffer? *If _kbhit() does not look
> at the buffer, what does it look at?


From the C-FAQ:

19.1: How can I read a single character from the keyboard without
waiting for the RETURN key? How can I stop characters from
being echoed on the screen as they're typed?

A: Alas, there is no standard or portable way to do these things in
C. Concepts such as screens and keyboards are not even
mentioned in the Standard, which deals only with simple I/O
"streams" of characters.

At some level, interactive keyboard input is usually collected
and presented to the requesting program a line at a time. This
gives the operating system a chance to support input line
editing (backspace/delete/rubout, etc.) in a consistent way,
without requiring that it be built into every program. Only
when the user is satisfied and presses the RETURN key (or
equivalent) is the line made available to the calling program.
Even if the calling program appears to be reading input a
character at a time (with getchar() or the like), the first call
blocks until the user has typed an entire line, at which point
potentially many characters become available and many character
requests (e.g. getchar() calls) are satisfied in quick
succession.

When a program wants to read each character immediately as it
arrives, its course of action will depend on where in the input
stream the line collection is happening and how it can be
disabled. Under some systems (e.g. MS-DOS, VMS in some modes),
a program can use a different or modified set of OS-level input
calls to bypass line-at-a-time input processing. Under other
systems (e.g. Unix, VMS in other modes), the part of the
operating system responsible for serial input (often called the
"terminal driver") must be placed in a mode which turns off
line-at-a-time processing, after which all calls to the usual
input routines (e.g. read(), getchar(), etc.) will return
characters immediately. Finally, a few systems (particularly
older, batch-oriented mainframes) perform input processing in
peripheral processors which cannot be told to do anything other
than line-at-a-time input.

Therefore, when you need to do character-at-a-time input (or
disable keyboard echo, which is an analogous problem), you will
have to use a technique specific to the system you're using,
assuming it provides one. Since comp.lang.c is oriented towards
those topics that the C language has defined support for, you
will usually get better answers to other questions by referring
to a system-specific newsgroup such as comp.unix.questions or
comp.os.msdos.programmer, and to the FAQ lists for these groups.
Note that the answers may differ even across variants of
otherwise similar systems (e.g. across different variants of
Unix); bear in mind when answering system-specific questions
that the answer that applies to your system may not apply to
everyone else's.

However, since these questions are frequently asked here, here
are brief answers for some common situations.

Some versions of curses have functions called cbreak(),
noecho(), and getch() which do what you want. If you're
specifically trying to read a short password without echo, you
might try getpass(). Under Unix, you can use ioctl() to play
with the terminal driver modes (CBREAK or RAW under "classic"
versions; ICANON, c_cc[VMIN] and c_cc[VTIME] under System V or
POSIX systems; ECHO under all versions), or in a pinch, system()
and the stty command. (For more information, see <sgtty.h> and
tty(4) under classic versions, <termio.h> and termio(4) under
System V, or <termios.h> and termios(4) under POSIX.) Under
MS-DOS, use getch() or getche(), or the corresponding BIOS
interrupts. Under VMS, try the Screen Management (SMG$)
routines, or curses, or issue low-level $QIO's with the
IO$_READVBLK function code (and perhaps IO$M_NOECHO, and others)
to ask for one character at a time. (It's also possible to set
character-at-a-time or "pass through" modes in the VMS terminal
driver.) Under other operating systems, you're on your own.

(As an aside, note that simply using setbuf() or setvbuf() to
set stdin to unbuffered will *not* generally serve to allow
character-at-a-time input.)

If you're trying to write a portable program, a good approach is
to define your own suite of three functions to (1) set the
terminal driver or input system into character-at-a-time mode
(if necessary), (2) get characters, and (3) return the terminal
driver to its initial state when the program is finished.
(Ideally, such a set of functions might be part of the C
Standard, some day.) The extended versions of this FAQ list
(see question 20.40) contain examples of such functions for
several popular systems.

See also question 19.2.

References: PCS Sec. 10 pp. 128-9, Sec. 10.1 pp. 130-1; POSIX
Sec. 7.

19.2: How can I find out if there are characters available for reading
(and if so, how many)? Alternatively, how can I do a read that
will not block if there are no characters available?

A: These, too, are entirely operating-system-specific. Some
versions of curses have a nodelay() function. Depending on your
system, you may also be able to use "nonblocking I/O", or a
system call named "select" or "poll", or the FIONREAD ioctl, or
c_cc[VTIME], or kbhit(), or rdchk(), or the O_NDELAY option to
open() or fcntl(). See also question 19.1.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
buffer creates only read-only buffer? Neal Becker Python 0 01-08-2009 01:58 AM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net 2 07-29-2008 09:50 AM
When using System.IO.FileStream, I write 8 bytes, then seek to the start of the file, does the 8 bytes get flushed on seek and the buffer become a readbuffer at that point instead of being a write buffer? DR ASP .Net Building Controls 0 07-29-2008 01:37 AM
convert M bit buffer to N bit buffer runcyclexcski@yahoo.com C++ 2 03-26-2007 09:43 AM
How to know the buffer size and increase buffer size in c++ Raja C++ 12 06-21-2004 06:21 PM



Advertisments