Is it possible to read keystroke ^C in a VIO session?

[Jon Saxton]

I needed a very simple terminal emulator (TE/2 & HALite each have more
features than I want) so I decided to write one. It works well enough
but I can't seem to get the thing to read a control-C from the
keyboard into a KBDKEYINFO struct.

To illustrate the problem I wrote a keyboard read/display program,
first using KbdCharIn(). If I turn off ^C notification then the
program doesn't abort on a ^C but the input buffer is unaltered - the
program reports the previous keystroke.

Thinking that I might need to bypass the KBD subsystem calls I wrote a
second version using DosDevIOCtl() but that reports an error 22 on the
read call. 22 is not a listed return code but as a generic base error
it means that the device (keyboard) doesn't recognise the command
(KBD_READCHAR).

Two questions:

1. Obviously I've screwed up my DosDevIOCtl() call but how?

2. Am I missing something obvious? Is there a (better) way to read
^C from the keyboard?

==========================

KbdCharIn() program ....

#define INCL_KBD
#include <os2.h>
#include <stdio.h>
#include <signal.h>

int main(int argc, char *argv[])
{
KBDKEYINFO
kbci;
int
escapes = 0;
HKBD
kbd = 0;
APIRET16
rc;

signal(SIGBREAK, SIG_IGN);
signal(SIGINT, SIG_IGN);

do
{
rc = KbdCharIn(&kbci, IO_WAIT, kbd);
printf("rc:%3d Char:%02X, Scan:%02X, Status:%02X,
Shift:%04X\n",
rc, kbci.chChar, kbci.chScan, kbci.fbStatus,
kbci.fsState);
if (kbci.chChar == 0x1B)
++escapes;
else
escapes = 0;
}
while (escapes < 2);

return 0;
}

========================

DosDevIOCtl() program

#define INCL_KBD
#define INCL_DOSDEVIOCTL
#define INCL_DOSDEVICES
#include <os2.h>
#include <stdio.h>
#include <signal.h>

int main(int argc, char *argv[])
{
KBDKEYINFO
kbci;
int
escapes = 0;
HFILE
kbd = 0;
APIRET
rc;
unsigned short
transferCount,
dummy = 0;
unsigned long
paramLen,
dataLen,
action;

// signal(SIGBREAK, SIG_IGN);
// signal(SIGINT, SIG_IGN);

rc = DosOpen("KBD$", &kbd, &action, 0, FILE_NORMAL,
FILE_OPEN,
OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE,
NULL);
if (rc)
{
printf("DosOpen(KBD$, ...) returned %d\n", rc);
return 1;
}
else
printf("Keyboard handle is 0x%08X\n", (unsigned long)kbd);

do
{
transferCount = 1;

rc = DosDevIOCtl(kbd, IOCTL_KEYBOARD, KBD_READCHAR,
&transferCount, sizeof transferCount,
&paramLen,
&kbci, sizeof kbci, &dataLen);
if (rc)
{
printf("DosDevIOCtl() returned %d (0x%04X)\n", rc, rc);
return 2;
}
else
{
printf("Char:%02X, Scan:%02X, Status:%02X, Shift:%04X\n",
kbci.chChar, kbci.chScan, kbci.fbStatus,
kbci.fsState);
if (kbci.chChar == 0x1B)
++escapes;
else
escapes = 0;
}
}
while (escapes < 2);

return 0;
}

--
Reply to: field is bogus. Respond to
Jon Saxton <triton /at/ ibm /dot/ net> OS/2 software developer
U.S. Agent for Triton Technologies International Ltd

[Jim Lewis]

Jon Saxton wrote:
>
> I needed a very simple terminal emulator (TE/2 & HALite each have more
> features than I want) so I decided to write one. It works well enough
> but I can't seem to get the thing to read a control-C from the
> keyboard into a KBDKEYINFO struct.
>
> To illustrate the problem I wrote a keyboard read/display program,
> first using KbdCharIn(). If I turn off ^C notification then the
> program doesn't abort on a ^C but the input buffer is unaltered - the
> program reports the previous keystroke.
>
> Thinking that I might need to bypass the KBD subsystem calls I wrote a
> second version using DosDevIOCtl() but that reports an error 22 on the
> read call. 22 is not a listed return code but as a generic base error
> it means that the device (keyboard) doesn't recognise the command
> (KBD_READCHAR).
>
> Two questions:
>
> 1. Obviously I've screwed up my DosDevIOCtl() call but how?
>
> 2. Am I missing something obvious? Is there a (better) way to read
> ^C from the keyboard?
>
> ==========================
>

In my text editor I used an exception handler to keep the user from
aborting the program with a Ctrl-C key press. I think you can examine
the data in the structure to determine what caused the exception and
handle it accordingly.

Jim Lewis
Not speaking for IBM.
Free OS/2 utilities and Java games - http://www.chauvet.com/jim.lewis

[Brian Havard]

nospam@here (Jon Saxton) writes:

>I needed a very simple terminal emulator (TE/2 & HALite each have more
>features than I want) so I decided to write one. It works well enough
>but I can't seem to get the thing to read a control-C from the
>keyboard into a KBDKEYINFO struct.

I think you just need to change the keyboard to binary mode using
KbdSetStatus().

--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------

[Peter Fitzsimmons]

Jon Saxton wrote:
>
> I needed a very simple terminal emulator (TE/2 & HALite each have more
> features than I want) so I decided to write one. It works well enough
> but I can't seem to get the thing to read a control-C from the
> keyboard into a KBDKEYINFO struct.

Set the keyboard to binary mode:

void setkmode(void)
{
KBDINFO kbstInfo;

kbstInfo.cb = sizeof(kbstInfo);
KbdGetStatus(&kbstInfo, 0);
kbstInfo.fsMask &= ~KEYBOARD_ASCII_MODE;
kbstInfo.fsMask |= KEYBOARD_BINARY_MODE ;//| KEYBOARD_SHIFT_REPORT;
KbdSetStatus(&kbstInfo, 0);

}

--
Peter Fitzsimmons, Toronto Canada.
email:pf...@ican.net Voice: 905-858-3222

[Jon Saxton]

On Thu, 17 Jun 1999 14:23:45, b...@silk.apana.org.au (Brian Havard)
wrote:

> nospam@here (Jon Saxton) writes:
>
> >I needed a very simple terminal emulator (TE/2 & HALite each have more
> >features than I want) so I decided to write one. It works well enough
> >but I can't seem to get the thing to read a control-C from the
> >keyboard into a KBDKEYINFO struct.
>

> I think you just need to change the keyboard to binary mode using
> KbdSetStatus().

Good answer. Worked perfectly. Thanks, mate.

Now how on earth did you know to do that?

[Brian Havard]

nospam@here (Jon Saxton) writes:

I've worked extensively with the Kbd* (and Vio*, Mou*) calls
while writing File Commander/2. After 6 years+ I've picked up
a few tricks :)