TInteractor objects represent a refined version of a general event distribution mechanism. Their design and implementation depend on your anticipation of the user's needs at a given point in the interaction with an application.
If you correctly anticipate a user's interaction with an application, you can direct the events generated in that interaction to the objects that want to know about them.
A single user interaction might be deconstructed into several finite actions resulting in state changes in the GUI or in the physical device accepting the input. For instance, a selection (a TMouseDown event received by a desktop icon) followed by a move, followed by a TMouseUp event would signal that the user wants to move an icon on the desktop.
In a conventional event distribution mechanism, this user interaction would result in a large number of events being distributed to all objects that might have an interest in the events.
Most would probably discard the information as not being pertinent, but your application would still have to distribute the events to objects which might be interested and allow the objects to make the choice. This mechanism is somewhat cumbersome if you need to manage many events.
When an event is received by an input device with a root TInteractor object, the event is received by the TInteractor as well. This root TInteractor distributes the event to a tree of TInteractor objects, all of which either change their state, or pass on the event to the next TInteractor (node) in the tree.
Eventually, an event will reach a TInteractor object in which it will effect a change. This change in the TInteractor's state may result in a change visible to the user (for instance, something being selected), or it may mark that something needs to be updated (for instance, an internal counter representing mouse position).
Each TInteractor object in the chain represents a state change in the GUI or the physical device, mirroring the decomposition of the user's gesture. A user interaction that results in a change of state can therefore be represented by a single TInteractor object that in turn references other TInteractor objects.
Client applications can reference this root TInteractor object and direct events to be distributed throughout the entire network of TInteractor objects, starting from the top down.
For example, when the developer of a GUI application anticipates that her application will receive a mouseDown event, she will create a TInteractor object that is capable of dealing with all possible outcomes of a gesture which is initiated by a mouseDown event. That TInteractor will probably be composed of several other TInteractors, each representing a possible state change.
Accordingly, you should design your application to turn off TInteractors when they are not in use. TInteractor objects are not in use when it is clear the user is not following the gesture represented by the TInteractor.
Gestures
The event stream that results from the user's interaction with the user interface is sometimes termed a gesture. A gesture can be interpreted by a program to encapsulate the user's intent because it ties a series of events together into a single interaction.
TInteractors and
input devices
TInteractor objects are bound to TInputDevices. There is normally a one-to-one correspondence between the number of top-level TInteractor objects in existence and the number of TInputDevices. The top-level TInteractor bound to the input device is called a root TInteractor. Deriving a
subclass
Derive a subclass of TInteractor when you need to parse a stream of events to determine a user's intent. You will need TInteractor objects to implement various aspects of higher level systems--such as the direct manipulation interface of a GUI toolkit. Activation and deactivation of TInteractors
An object which holds a reference to a TInteractor object is responsible for activating and deactivating the TInteractor. The object holding the reference must activate the TInteractor before the TInteractor object receives an event. (Inactive TInteractor objects reject all events.) Event receiver
handles
The TEventReceiverHandle object forms an application's communication link from the input system and creates a thread which a TEventReceiver object can execute. Because the TEventReceiverHandle is the communication link to the input system it is also the source of the application's identity from the point of view of the input system. Event receiver
surrogates
TEventReceiverSurrogate objects are created from TEventReceiverHandle objects. TEventReceiverSurrogate objects are lightweight objects that exist only to identify event receivers across tasks. TEventReceiverSurrogate objects can block the TEventReceiver object they represent until it has shut down. Applications which need to make sure that a TEventReceiver has shut down before continuing should use the blocking protocol provided by the surrogate.
[Contents]
[Previous]
[Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Generated with WebMaker