There are two main event sources in the FPS system:
- the directly called processes like the capture process, which can raise events to report their progress,
- the parallel running freerun mode tasks, which can raise events to report state changes like finger presence detection or button testing.
The following programming technics are implemented:
- callback function
- window messages
- ActiveX events
The raised event can be filtered with the event_types property. The event type values are defined in the FPS_EVENT
enumeration as well as the event values.
The user implemented callback function have to be registered with the
SetEventFunction function.
If the capture is started asynchronously by the
CaptureStart function, then the callback function is called only during the
CaptureStatus or the
CaptureWait functions are called. This behaviour can be changed with the
async_callback property. Use this property with precaution because user programs might hang up in case of calling Windows functions from an internal capture thread that doesn't own a message queue.
The freerun mode tasks can be called periodically by the user program or an asynchronous background process can be started with the
BeginWindowMessaging or
StartBGProcesses functions. Currently this kind of event handling is available only in the C/C++ interface.
Windows programs can get window messages from the FPS system after a window handle is set by the
BeginWindowMessaging function. User programs have to set a range of 32 message ids. The capture events and the freerun mode events both post messages even in asynchronous mode. The message value is
base_msg + id, where
base_msg is the user defined base offset and
id is one of the ids defined in the
FPS_WND_MESSAGE
enumeration.
The ActiveX component of the FPS system supports all event types: the
FPSEvent event is raised by the capture process, the
FingerPresenceEvent ,
PreviewEvent,
ButtonEvent,
PowerEvent or
ConnectionEvent events are raised by the freerun mode tasks. As the freerun mode events have their individual event methods the event filtering is not applied to them.
- Image captured: This event is raised when an image has been captured. The first parameter of this event is reserved. The second parameter is the finger position.
- Capture Finished: This event is raised when the capture process has been finished. The parameters of this event are reserved.
- Fingers captured: This event gives information about hand positioning. The first parameter is reserved and the second stores the finger failure mask.
- Preview captured: This event is raised when the freerun mode is set to enable preview light and a preview image has been captured. This event has no parameters. Alternatively this event is raised during the capture process too.
- Finger presence detection: This event is raised when the freerun mode is set to enable finger presence detection and the state of the detector module has been changed. The parameter of this event shows the status of the presence test.
- Button: This event is raised when a button is pressed or released on the device. The first parameter of the event is the key code of the button; the second is the final state of the button.
- Power: This event is raised when the power state or the battery state of the device has been changed. The test that generates this event is running periodically so the event might be raised with a short delay. The first parameter of the event is the power and battery state. The second parameter is the battery level of the device.
- Connection: When no device is used and a device is plugged in or unplugged this event is raised. When a device is used this event occurs only when the used device is unplugged. The first and only parameter of the event is the sign of connection which is positive in case of new connection and negative in case of disconnection.