From: fox AT pt0204 DOT pto DOT ford DOT com (Ken Fox)
Subject: Re: custom keyboard interrupt handler?
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Mon, 19 Jul 1993 17:18:01 -0400 (EDT)
Cc: fox AT pt0204 DOT pto DOT ford DOT com (Ken Fox)


I've recieved many replies on this topic.

To re-iterate what I need:  I need event driven notification of keypresses
so that I can intercept a "magic key" and toggle a graphics mode.  The
program is not running an event loop - it has a sequential flow of control
that assumes a persistent plotter type graphics interface.  (This stuff is
old... :-)

What I've finally decided I need is a user-defined hook on _ev_keybdhandler
that has few or no restrictions on what code can be run in it.  This hook
would run every time a keypress occurs.  Mostly it would be used as a
filter; event driven programs have much better control structures available
to them.

Dr. Valery Fine has told me that he has sent routines that perform this
function to Csaba.  I'm going to pursue this direction further.  If anyone
else has used this code, thinks code like this is useful, or has
implementations of similar functionality; I'd be interested in hearing about
them.

As it looks like a modification to go32 is necessary, I'm either going to
have to get an appropriate development environment on the PC, or ask someone
to build a version of go32 for me.  What would it take to do either?

An aside to the group as a whole:  This has got to be one of the most
active/useful/friendly groups I've ever seen.  How come this DOS extender is
such a well-kept secret?  8-)

What follows is a brief summary of some of the mail I've received:

Mat Hostetter writes:
> Is Csaba's event queue library insufficient for your needs?  Do you
> have to be interrupt driven?

This only passively queue's the events and continues with the main execution
flow.  It doesn't allow for user hooks.

DJ Delorie writes:
> Why don't you just use kbhit() and getkey() to monitor the keyboard?
> It's a lot simpler than trying to trap keyboard interrupts.

I write and don't have control over the execution models of the programs
that are running.  Certainly I don't want to rewrite them to use an event
driven structure.

Mat Hostetter writes:
> Check out mousedraw_hook() in exphdlr.c, and check out Csaba's event  
> queue code on the protected mode side.

This looks promising.  I assume that this is essentially what Dr. Fine has
written - only for the keyboard.

Henry Tieman writes:
> I think you are working on this too hard.  It is probably easier to
> take a memory intensive approach and use the built in getch function.
> This would involve three parts:
> 1) using a memory area for graphics and bliting to the screen as needed.
> 2) getting text to go to memory.
> 3) setting the screen mode and copying the right memory to the screen
>    when needed.
> The first one is free by using memory regions instead of the screen.  The
> second one takes some work.  And the third one is 'just' programming.

This is essentially what my keypress hook would do:  switch graphics mode
and update the screen display.  I just need a way to call it on demand.
And no restriction that I can't do graphics from inside a hook!

Henry Tieman writes:
> I just thought about the reason for an interupt - not wanting to put in an
> explicit call to a graphics display function inside the main loop of your
> program and doing the display by using signal()(or equilavent.)  If I wanted
> to write this code - I would look to see if signal() is supported and hack a
> copy of the kbhit function(fron the libsrc tree) to generate a SIGUSR1 to a
> graphics display function.  There are many variations of this if signal() is
> not supported.

I'm not sure what using signal() would do for me.  I think Henry is
suggesting to install a signal handler, but on what signal?  On a BSD Unix
box I could set the signal on SIGIO.  Does the djgcc support this???

Thanks again to everyone who sent replies.

-- 
Ken Fox (fox AT pt0204 DOT pto DOT ford DOT com)  | My opinions or statements do not
                                   | represent those of, nor are endorsed by,
                                   | Ford Motor Company.
CAD/CAM Technology Section         |
CAD/CAM/CAE Process Integration    | "Is this some sort of trick question
Ford Motor Company                 |  or what?" -- Calvin