🚀 go-pugleaf

cwilkins@irscscm.UUCP (Charlie Wilkinson) writes:

>bbrown@infonode.ingr.com (Bailey Brown) writes:
>: cwilkins@irscscm.UUCP (Charlie Wilkinson) writes:
>: 
>: >bbrown@infonode.ingr.com (Bailey Brown) writes:
>: >: I am writing a program and I want to use the CTRL_P key combination
>: >: in it.  I am using bioskey() to read keys.  When I press "ctrl-p"
>: >: my program does not see it, and when I exit my program, I get an
>: >: "abort retry fail ignore" message because the printer isn't turned
>: >: on.  At first I thought 4dos was up to something, but the docs say
>: >: that ctrl-p is intercepted by the bios and has something to do
>: >: with printscreen.  I there any way to get around this behavior?
> 
>stuff deleted...]

>: Well, while looking for some sample code to install a keyboard
>: interrupt handler, I came across the following code that lets
>: you detect and read any key combo, including ctrl+p, without 
>: starting the "printer not ready" monkey business.
>: 
>: To detect a keypress:
>: 
>:     int flags;
>:     union REGS reg;
>: 
>:     reg.x.ax = 0x4406;
>:     reg.x.bx = 0;
>:     int86(0x21,&reg,&reg);
>:     flags = reg.h.al;
>:     if (flags & 1)
>:         return TRUE;
>:     else
>:         return FALSE;
>: 
>That's a DOS call there.  You can do the same thing better by going right
>to BIOS INT16h Function 01 "Get keyboard status".  The following was written
>for MSC 6.0, but a little modifying and you should be able to plug it into
>just about anything:

>/*
> * This function tests the keyboard to see if a key is waiting.
> * 0 = no key waiting
> * 1 = key waiting
> */
>int test_key( void )
>{
>   int stat = 0;

>      _asm{
>         push ax
>         mov ax, 0100h
>         int 16h
>         mov stat, 0
>         jz DONE
>         mov stat, 0001h
>      DONE:
>         pop ax
>      }

>   return( stat );
>}

>: 
>: and to read the key:
>: 
>: 
>:     int c;
>: 
>:     union REGS reg;
>:     reg.h.ah = 0x10;
>:     int86(0x16, &reg, &reg);
>:     c = reg.x.ax;
>: 
>:     if ((c & 0xff) == 0 || (c & 0xff) == 0xe0)
>:         c = (c >> 8) | 0x1080;
>:     else
>:         c &= 0xff;
>:     c = c & 0x10ff;
>:     return c;
>: 

>The code above has the advantage of being able to distinguish left from right
>control keys, etc.  If you don't need that feature, you might want to avoid
>INT16h Function 10h because it works on AT's and up *only*.  A more generic
>function would be INT16h func 00h.  Here is a function that reads keypresses,
>you would have to add the ^P filter yourself:

>/*
> * The get_key() function sits and waits for a keypress.  When a key is
> * pressed, the value is returned.  The global int variable ext_ascii will
> * be set if the keypress was a function key, control key combination, etc...
> * This function goes directly to BIOS (Do not collect $200...)
> */
>int get_key( void )
>{
>   int key = 0;

>   _asm{
>      push ax
>      mov ax, 0
>      int 16h
>      mov key, al
>      mov ext_ascii, 0
>      test al, 0ffh
>      jnz DONE
>      mov key, ah
>      mov ext_ascii, 0001h
>   DONE:
>      pop ax
>   }

>   return( key );
>}

>Not exactly award-winning, but it gets the job done.  For what it's worth,
>these two functions (test_key and get_key) were pulled from the same working
>program.  If you are thrown completely by the in-line assy (it happens...),
>drop me a note and I'll dig up something more C friendly.

>: Is this code general?  Will it work on any (386 AT or better) dos box?
>: How does it work?  It looks like it is getting the key from dos.  I
>: thought dos was higher level than the bios, and therefore would
>: have as least as much bad ctrl+p type behavior as the bios.
>: Please shed some light.  All I know is this works on my machine.

>A friend here at work was reading over my shoulder and decided to do some
>testing.  He found that ^P appears to be part of DOS and not BIOS.  This
>means that using BIOS as you have, would bypass the DOS testing of the
>keypress thereby effectively disabling the ^P printer handler.

>--
>cwilkins@irscscm.uucp                                   /======================\
>uunet!mimsy!prometheus!media!ka3ovk!irscscm!cwilkins    | Micro-Sig(tm) pellet |
>N3HAZ@KA3RFE.MD.USA.NA                                  |   -just add water    |
>...or you can call me Charlie                           \======================/


Hi there !

I have similar problems. Could the  above described solutions also
catch such keystrokes as Ctrl-Break, Ctrl-C and Pause.
I'm developing a data acquisition program which should not be
interrupted by such accidental keystrokes. If not, please let me know
about other possible solutions.

Thanks for any help,

Sauli Toivonen

Department of Forensic Medicine
University of Turku
Finland

E-Mail: sautoivo@utu.fi