Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!lll-winken!sun-barr!newstop!sun!imagen!qmsseq!pipkins
From: pipkins@qmsseq.imagen.com (Jeff Pipkins)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Mouse Event Handler Questions
Message-ID: <119@qmsseq.imagen.com>
Date: 26 Feb 90 17:04:42 GMT
References: <29630001@hpfinote.HP.COM> <22430@uflorida.cis.ufl.EDU>
Reply-To: pipkins@qmsseq.UUCP (Jeff Pipkins)
Organization: QMS Inc., Mobile, Alabama
Lines: 55

In a previous article jhs@hpfinote.HP.COM (John Stanback) writes:
>I'm trying to install a mouse event handler function using TurboC 1.5
>with the medium memory model.  The mouse handler is installed using
>INT 33, function 12.  The references I've seen to doing this use
>an area in the PSP to store the mouse event status and access this
>memory referencing _CS in the mouse handler.  This seems to work in
>the small memory model, but not in the medium.  How can I store the
>mouse event status using the medium memory model????   Also, I would
>like to be able to access the programs global variables from the
>mouse handler.  Is this possible???

There is no reason to make this solution so hard.  Elaborate hacks
involving PSPs (such as some that have been suggested) are not just
ugly, they're overkill as well.  This problem is much simpler than
that, and no undocumented information is required.

First of all, the PSP is no place to store mouse data.  In .EXE files,
the CS register does not give proper access to it anyway.

I am not familiar with Turdo C's library functions for mouse handling,
but I have written mouse handlers in ASM and interfaced them to MSC.
If you use the "interrupt" keyword to create a C function with interrupt
entry code (not great style, but it works), you can do the same in C.
This C interrupt function can access global or local static storage
just like any other C function.  No magic necessary.

Suggestion dept:
Create a source file (maybe mouse.c) to hold all functions you will write
concerning mouse support.  If these functions need to share memory, define
this memory at the top of the file and declare it "static".  This means
that only functions in this source file can access it.  Do not define
globals.  Instead, define functions that will return values of interest.
This approach will separate the mouse functions from the applications, so 
that later you can modify the mouse functions without having to modify
the apps.

An event queue is a very nice way to handle a mouse, but there is not much
literature on it that I have seen.  It is simple to implement.  You just
create a circular queue.  There is a lot of literature on that.  (See Knuth)
When the interrupt handler gets invoked (an event has occurred), all it
does is insert a token in the event queue representing the event.  Entries
may have room to store additional information, like position.

A separate C function can then easily read these events from the queue and
process them.  A finite state machine is useful for this purpose.  The
most straightforward version is a switch construct inside a loop.

The nicest feature of this architecture is that you don't have to worry
about calling nonreentrant functions (or DOS) from the interrupt handler,
and you don't have nightmares about interrupt handlers accessing global
variables.

Hope this helps.
-Jeff Pipkins
pipkins@imagen.com