In addition to displaying lines, you should be able to control the presentation from the touchscreen. If the lights in the room have been dimmed or if the PC is distant from the overhead projector you may have trouble using the keyboard. To control the presentation from the touchscreen, you must be (touchscreen touches that trace lines) and button-type touches (touches that control or switch between functions). For example, button touches might command presentation software to zoom in on a region of interest on the displayed image, to save an image after it has been drawn into and modified, or to return an image to its original, unmodified state.

Touchscreen controllers may be mounted either in a separate box and accessed via a PC's RS232 port, or located on a circuit board that inserts directly into the PC's bus. Bus type controllers interpret and return touch points at a greater rate than RS232 type controllers, other things being equal.

An application program and the ELODEV TSR communicate through a user-programmable software interrupt. Multiple copies of the ELODEV TSR can be present to control multiple touchscreens and, when not in use, individual copies can be removed from memory. ELODEV responds to 26 different commands and, because it is a TSR, can be called easily from C. Its C interface provides the following interrupt functions:

• driverinfo - returns touchscreen hardware and status information
• opentouch - prepares the touchscreen for use
• closetouch - terminates touchscreen use
• enabletouch - enables touchscreen interrupts
• disabletouch - disables touchscreen interrupts
• setcalibrange - calibrates the touchscreen
• gettouch - returns touch-point coordinate values

Of the 26 functions to which the ELODEV TSR responds, only one, gettouch, returns touch-point coordinates. This function takes three arguments, xt, yt, and ut. xt and yt are pointers to ints and return a touch-point coordinate (x_t, y_t). ut is a pointer to a boolean and returns the untouch logical value. If ut is TRUE, then the user removed a finger from the touchscreen, making the area the finger vacated the last touch point for the current touch. gettouch also returns a boolean value. If TRUE, then a touch was present. If FALSE, then a touch was not present. (The ELODEV C interface typedefs boolean to be an unsigned char.)

Uncalibrated values of touch-point coordinates range from (0,0) to (4095,4095). Touches may be calibrated and translated using an ELODEV function that changes the default characteristics of the touch screen controller and software. One useful coordinate mapping scheme instructs the ELODEV TSR to return touch-point coordinates ranging from (0,0) to (639,479) (the graphics coordinate range of a PC's VGA screen) assuming that lines are to be drawn directly into the VGA image. The modules I describe in this article will work with any touchscreen calibration; however, the example program only demonstrates using a touchscreen in its native (or uncalibrated, untranslated) mode.

The distance, d_i, between the most recent touch point (x_i, y_i) and the touch centroid (x_cen, y_cen) is

Therefore, if the touch is a button type and r_b is the imaginary button radius, then d_i <= r_b for 1 < in. If d_i > r_b for any i, then the touch is a curve type.

The general design of GetTouch follows the rule that if the touch is a button type, then d_i <= r_b for 1 < i <= n. This implies that every touch's touch point must be examined before a determination can be made about the touch type. Since the number of touch points for a touch cannot be known in advance, what do you do? Each touch point could be malloced into a simple linked list, but this solution would preclude using the function GetTouch in a TSR application. In practice, however, I've found that button touches are much shorter in duration than curve touches. It follows that the shorter the touch duration, the fewer the touch points. So even though the total number of touch points for a button touch is never known in advance, choosing a reasonably large static touch buffer (and carefully crafting a few explanatory words about brief button touches in any user documentation) will suffice. Changing the #defined value of TOUCH_BUF_NUM easily changes the size of GetTouch.c's touch buffer.

SetButtonRadius, appropriately, sets the button radius, rb. It takes one argument, the value of the button radius (in appropriate units). I've found that between 4% to 8% of the diagonal dimension of the touchscreen's touch area is a reasonable range for button radii. For example,

where (x_min, y_min) and (x_max, y_max) are the current touchscreen minimum and maximum calibrated and translated coordinate values.

ReplayTouch does what its name implies, but only works if GetTouch.c's internal touch buffer holds an entire touch. If not, then nothing happens. If it does hold a complete touch, then a subsequent call to GetTouch will replay it. ReplayTouch accepts an argument that overrides the button-type logical value for the touch. The typical use for this function occurs if a user dots an 'i' while writing on the touchscreen. Since GetTouch normally interprets the dot of an 'i' to be a button touch, ReplayTouch permits overriding this default behavior and drawing a dot on the 'i'.

Lastly, TouchInfo returns a pointer to a touchit struct that contains the values of the touch point (X_cen, y_cen) centroid, the number of touch points, and the button-type indicator.