Data Confirmation Feature - Socket ScanAPI Reference Manual

Socket ScanAPI Reference
The symbology enumeration begins by calling the Get API with the property
initialized to kSktScanSymbologyNotSpecified+1 to retrieve the status of the first
symbology. The property must then have its Symbology field set correctly with its ID
equal to the returned symbology type, e.g. kSktScanSymbologyAustraliaPost if that
was the first symbology returned.
When the application receives the Get complete message, it updates the status for
the symbology specified in the property, and it can then increment the symbology id
and check if it is not equal to kSktScanSymbologyLastSymbologyID. If it is then the
application is done enumerating the symbologies for this device. If it is not equal
then the application can continue the symbology enumeration by calling again
SktScanGet with this new symbology id.
If the Get API returns a not supported error (ESKT_NOTSUPPORTED) or if the Get
Complete event returns the same error, then this symbology is not supported by the
connected device, and it is safe to move to the next symbology ID if it is different
from kSktScanSymbologyLastSymbologyID.
This operation of enumerating the symbologies of a device can be lengthy. It is
recommended to use Symbology cache logic in conjunction with the Change ID
feature. The cache is filled the first time by enumerating all of the symbologies of a
device, and the Change ID is store in the cache as well. When the device reconnects,
the application requests the device Change ID and compares it with the one stored
in the local cache.

17 Data confirmation feature

The data confirmation feature allows an application to control how the decoded
data is confirmed.
This feature is mostly useful when the operator is distant from the host.
The confirmation can be generated at three different levels: locally on the device,
remotely on the host by ScanAPI, or remotely on the host by the application
itself.
In order to indicate to ScanAPI at which level the data confirmation should be
done, the kSktScanPropIdDataConfirmationMode should be set with its byte
value set to the appropriate value. If the choice is to have either ScanAPI or the
device to confirm the decoded data, there is another property that needs to be
used in order to specify what action should be made when ScanAPI or the device
confirms the data. An action is a combination of beep, LED flashing and Rumble.
If the application is the level chosen for confirming data, the application needs to
send a confirmation by doing a property set operation with the property ID set
© 2013 Socket Mobile, Inc. 130/152