This article explains how you can dispatch custom TLcdTouchEvent
instances and other input events into your LuciadLightspeed application. It also contains the necessary information for making
your custom touch device work with the existing LuciadLightspeed touch controllers.
Dispatching custom input events
To dispatch your custom TLcdAWTEvent
instances to the GXY views, you can make use of the dispatchEvent
method of Component
. The GXY views by default forward all received TLcdAWTEvent
instances to its controller if the latter implements ILcdAWTEventListener
.
Take care when determining the target of your custom TLcdAWTEvent
. You might end up dispatching your event to a Component
that lies on top of the view.
Receiving LuciadLightspeed touch events
LuciadLightspeed dispatches its supported touch events by mapping the first touch point to a target component. It then uses
the dispatchEvent
method of the target component to get the event to the component. To handle touch events in your component, you can override
processEvent
. Take care if your component has siblings: the event might wind up in a different component than the one you expect. Note
that the view implementations contain methods to add and/or remove ILcdAWTEventListener
instances. Just like with MouseListeners
and KeyListeners
, as soon as one such a listener is registered, the corresponding incoming events are handled by this component. The events
are handled by passing the event to the registered listeners. For these classes, there is no need to override the processEvent
method.
To receive TLcdAWTEvent
instances for the entire application, you can make use of TLcdAWTEventDispatcher
. This is the central access point to dispatch TLcdAWTEvent
instances into the application. It allows you to register ILcdAWTEventListener
instances to be notified of any dispatched TLcdAWTEvent
.
Creating and understanding touch events
LuciadLightspeed provides support for Swing applications on devices compatible with Windows 7 Touch. You can use the method
TLcdTouchDevice.getTouchDeviceStatus()
to check if your device is supported. The TLcdTouchDevice
class also encapsulates some touch-specific settings, for example, to configure double tap behavior.
Don’t use TLcdTouchDevice in JavaFX applications: JavaFX comes with built-in multi-touch support.
All Lightspeed touch controllers automatically convert these events into TLcdTouchEvent .
|
If you have a custom touch device, or if you are working on another operating system and want to get its output to the LuciadLightspeed
touch controllers, you can create your own TLcdTouchEvent
instances.
The most important properties of touch events are:
-
Each touch event contains all fingers that are touching the screen
-
All touch events generated from the moment a finger touches the screen have the same ID until all fingers are lifted again
-
A touch event only includes one single change, such as one moved finger, or one lifted finger
-
the event’s target component is that of the first finger touching the screen
-
A touch event includes double-tap information (as Java’s
MouseEvent
). A double-tap originates in two separate events: one for the first tap, and one for the second.
The main classes are TLcdTouchEvent
, an extension of AWTEvent
representing (multi-)touch input and TLcdTouchPoint
, a class describing the state of one touch input point.
Associated with every touch input point is a TLcdTouchPoint
, describing the (change in) state of a single
touch input point. These TLcdTouchPoint
instances are then used in every TLcdTouchEvent
instance to describe the whole touch input.
A touch point can have four different states which are grouped in the TLcdTouchPoint.State
enumeration.
When touch points change state, the application is warned by means of a TLcdTouchEvent
. This event contains TLcdTouchPoint
instances for every touch point, both the one that has changed state as well as the ones which remained unchanged. Hence
there exists a one-to-one mapping between changes in the touch input points and the created TLcdTouchEvent
instances. Every TLdTouchEvent
instance contains exactly one TLcdTouchPoint
with a non-stationary touch point state.
Every touch point has a unique identifier which remains constant for a touch point as long as it exists.
This identifier is assigned when the touch point is created, and all other TLcdTouchPoint
instances
describing (a change in) the state of that particular touch point will have the same identifier. As long as
the touch point exists, no other existing touch point from the same touch device and the same user may
have the same identifier.
This allows to track movements and/or state of multiple touch points simultaneously. As soon as a touch point is removed and the tap count no longer increases, this identifier becomes available and may be reused to describe the state of a new touch point.
Similar to the TLcdTouchPoint
instances, every TLcdTouchEvent
instance has a unique ID. This ID is assigned
when the first touch point is created, and remains the same until all touch points are removed.
Once all touch points are removed, the next touch point that is created:
-
Generates a new
TLcdTouchEvent
with the same ID as the current event if, and only if, the new touch point increases the tap count of one of the previously removed touch points. -
Generates a new
TLcdTouchEvent
with an ID different from the one of the current event. The ID of the current event may be reused later on.
Note that both the ID of the TLcdTouchPoint
and TLcdTouchEvent
instances are only unique for a
certain user and device combination. You can retrieve the identifiers for the user and the device from the
TLcdTouchEvent
instances.
The creation of TLcdTouchEvent
instances is demonstrated in the touch.touchEvents
sample. In this sample,
touch hardware is simulated by an object that generates a stream of hardware events. These hardware events are then converted
to TLcdTouchEvent
instances and dispatched.