General event mechanisms

Before turning to an exposition of how the input system deals with specific input devices, you should have some familiarity with the general client generation and event distribution mechanisms.

Creating and deleting input devices

The TEventSender base class defines the primary mechanism for sending an event in the CommonPoint application system. When your application instantiates a TEventSender object, the application becomes an input device. Correspondingly, when your application deletes the TEventSender object, it ceases to be an input device.

NOTE You can assume that there will always be a one-to-one correspondence between the number of TEventSender objects existing in the system and the number of input devices active in the system.

How input devices work

The TInputDevice base class represents the input device to the application. Applications do not interact directly with input devices. Rather, they interact with TInputDevice objects that exist in the context of the application task.

You can derive a subclass from TInputDevices to provide special message-handling behavior--turning messages into events that applications can understand.


Figure 10 illustrates the interaction between the physical input device and the TInputDevice that exists only in the context of the application with which it is communicating.

TInputDevice objects store the state of the input device. The TInputDevice object is capable of creating a snapshot of the state of the input device that can be read by another input device of the same type.

NOTE This snapshot is useful if you want to provide client applications with the state of the input device.

The structure of an event

A TEvent object is a packaged user interaction. An event typically contains information about where in the address space of the physical device the event took place, the nature of the type of event, and some state information about the physical device.

These events can be distributed to one or more applications that have expressed interest in these events to the operating system.

How an event is sent

If your application sends events, it should use the TEventSender class. Other frameworks that define input device types will also use the TEventSender class.

The TEventSender class has a limited number of methods. TEventSender objects can construct and destroy a TInputDevice and can send a message to a TInputDevice object in a target application. The message is a stream of data which is converted to events by the receiving input device.

Surrogate event senders

Just as documents can be identified across tasks by document surrogates, TEventSender objects can be identified across tasks by surrogate event senders. TEventSenderSurrogates are lightweight objects that exist only to identify input devices across tasks. They are very simple objects, providing member functions for a test of validity and for identity comparison.

How events are created

Events are created by TInputDevice objects in response to a message from the TInputDevice's associated device driver. Using events, an input device writer can call a specific method on an event-handling object. The event-handling object then distributes this event to the appropriate target objects.


The device driver task that controls the input device creates a TInputDevice object in the address space of the application task.

Event distribution policies

You will often find it desirable to specify a particular set of rules for event distribution. The TEventReceiverTargetter class defines a functor that implements a standard event distribution policy for the input system.

When you are designing the input system you can distribute events through a TEventSender object or use a TEventReceiverTargetter object. TEventSender objects target a specific TEventReceiver object.

Conversely, a TEventReceiverTargetter distributes the event in a manner consistent with the event targeting policy you have designed into it. In this way you can use a different event distribution policy for a single application.

Receiving events

TStandardEventReceiver objects provide applications with a standard set of behaviors to deal with just received events. The input system requires this standardization.

TStandardEventReceiver objects can:

NOTE Derive a subclass from TStandardEventReceiver in order to add behaviors to the standard set provided.

Writing your own event receiver

If you are writing your own event receiver, you must support these functions:

These member functions are used by the event system to keep the client up
to date.


[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker