How it Works
Socket
Loading...
SocketScan SDK
User Manual
82 pgs454.77 Kb0

Socket SocketScan SDK User Manual

Download
Page 1
SocketScan
™
SDK User’s Guide
&
ScanAPI: Scanning Application Program Interface
April 8, 2010
Page 2
4/2010 Document # 6410-00147 K
Copyright Notice
Copyright © 1999-2010 Socket Mobile, Inc. All rights reserved.
Socket, the Socket logo, Mobility Friendly, SocketScan, Socket Bluetooth Cordless Ring Scanner, Socket Bluetooth Cordless Hand Scanner, CF Scan Card, SD Scan Card, CF Mag Stripe Reader Card, CF RFID Reader Card, and CF RFID Reader-Scan Card are registered trademarks or trademarks of Socket Mobile, Inc. The Bluetooth word mark and logo are registered trademarks of the Bluetooth SIG, Inc., USA, and any use by Socket Mobile is under license. All other brand and product names are trademarks of their respective holders.
Reproduction of the contents of this manual without the permission of Socket Mobile is expressly prohibited. Please be aware that the products described in this manual may change without notice.
Feel free to contact Socket Mobile at:
Socket Mobile, Inc.
39700 Eureka Drive Newark, CA 94560 USA
Web:
www.socketmobile.com/contact
Phone: +1-510-933-3000 USA & Canada Toll-free: 1-800-552-3300
Other than the above, Socket Mobile can assume no responsibility for anything resulting from the application of information contained in this manual.
You can track new product releases, software updates and technical bulletins by visiting:
www.socketmobile.com.
April 8, 2010 Page 2 Document#: 6410-00147 K Revision 2.28
Page 3
Revision History
Revision Date Author Comments
1.00 10/26/1999 G. Cuevas, L. Ott Genesis.
1.01 11/01/1999 G. Cuevas, J. Houston
1.02 11/02/1999 G. Cuevas, L. Ott Additional corrections.
1.03 11/04/1999 G. Cuevas Changed keyboard wedge product name to SocketScan.
1.04 11/04/1999 G. Cuevas Corrected registry entry section.
1.05 11/13/1999 G. Cuevas Updated for disk layout change.
2.00 03/29/2000 G. Cuevas Additions for Win32 Desktop, Preview DLL, Bar Code Wand.
2.01 05/06/2000
2.02 05/10/2000 G. Cuevas, P. Subbaraya Additional edits.
2.03 05/12/2000 G. Cuevas, P. Subbaraya Additions and corrections.
2.04 05/15/2000
2.05 05/17/2000 G. Cuevas, P. Subbaraya Minor edits.
2.06 05/23/2000 G. Cuevas, P. Subbaraya Additional minor changes.
2.07 12/11/2000 G. Cuevas Updates for HPC 2000, Windows 2000 and Windows Me.
2.08 12/20/2000 G. Cuevas, M. Man Minor edits.
2.09 12/20/2000 G. Cuevas Minor edits.
2.10 9/27/2001 T. Newman
2.11 12/17/2002 D. Acquistapace Added ScanParamSend and ScanParamRequest API calls (WinCE).
2.12 12/23/2002 P. Subbaraya
2.13 07/11/2003 P. Subbaraya
2.14 01/22/2004 P. Subbaraya
2.15 08/11/2004 D. Singh, S. Gutti Updated CHS information, modified desktop information
2.16 08/30/2004 T. Newman RFID Reader functions added
2.17 10/28/2004 S. Gutti Updated CHS information for Windows XP.
2.18 11/16/2004 D. Singh Added SDK Quick Start guide
2.19 12/08/2004 D. Singh Update ScanGetData() details and Section 4 and 12 for specific DLLs
2.20 01/07/2005 S. Gutti
2.21 03/17/2005 S. Gutti Updated ScanEnableCHS() & ScanDisableCHS() APIs
2.22 06/09/2005 S. Gutti Added new APIs to handle symbologies for all Scanners
2.23 09/23/2005
2.24 01/27/2006 A. Hersh Minor edits to reflect WM 5.0 support, MSR and CRS.
2.25 08/22/2006 A. Hersh Minor edits
2.26 11/29/2007 D. Acquistapace Edited for 5X support and new SDK directory structure
2.27 10/02/2008 E. Glaenzer Added ScanCommandFeature API to support the RFID AFI feature.
2.28 4/7/10 E. Glaenzer
G. Cuevas, P. Subbaraya, J. Houston
G. Cuevas, P. Subbaraya, J. Houston
A. Hersh, D. Singh, T. Newman, M. Man
Updated registry section; added correct doc number; cleaned up typos, etc.
General edits and corrections.
Minor edits.
Changes for SocketScan 3.2. Added ScanGetStatus() API call (WinCE). Polling calls from Embedded Visual Basic (EVB). Minor edits to API calls.
Changes for SocketScan 4.0 to support the 2DSC for bar code. Minor edits Changes for SocketScan 4.0 to support the 2DSC ScanSendCommand() API call(WinCE.) Changes for SocketScan 4.1.xx to support DriverMan registry structure. Minor edits.
Add new APIs for CHS configuration commands in Section 8.0 & 9.0 and updated registry entry section
Added CF RFID Reader-Scan Card APIs, CHS programming info, and SocketScan Trigger Applications
Added ScanCheckVersion API, and the Scanner Property APIs. Added a paragraph regarding ActivePairing and Permanent Pair features.
April 8, 2010 Page 3 Document#: 6410-00147 K Revision 2.28
Page 4
Table of Contents
1.0 Introduction .....................................................................................................................................7
1.1 SDK Quick Start Guide ............................................................................................................8
2.0 Revision Notes..................................................................................................................................9
2.1 Windows CE............................................................................................................................. 9
2.2 Windows Desktop/Notebook ................................................................................................. 9
3.0 Using ScanAPI.................................................................................................................................11
3.1 SDK Initialization/De-initialization ......................................................................................11
3.2 Device Control.......................................................................................................................11
3.3 Scanner Data Access.............................................................................................................. 11
3.4 Miscellaneous Utility.............................................................................................................11
3.5 Cordless Scanner Specific Functions.....................................................................................12
3.6 RFID Specific Functions ......................................................................................................... 12
4.0 Setting Up The Target Device .......................................................................................................13
4.1 Setting up Windows CE Devices...........................................................................................13
5.0 Writing Your Application..............................................................................................................14
5.1 Preview DLL ........................................................................................................................... 15
5.2 RFID Demo.............................................................................................................................15
5.3 ScanApiTester........................................................................................................................15
5.4 TriggerSample ....................................................................................................................... 15
5.5 CSharp Sample ......................................................................................................................15
5.6 Combo Card CSharp Sample................................................................................................. 15
5.7 RFID VB ..................................................................................................................................15
5.8 VB Sample..............................................................................................................................15
6.0 Soft Triggering...............................................................................................................................17
7.0 ScanAPI Type Reference ................................................................................................................ 18
8.0 ScanAPI Function Reference.......................................................................................................... 21
8.1 ScanCheckVersion ................................................................................................................. 21
8.2 ScanInit()................................................................................................................................22
8.3 ScanOpenDevice() ................................................................................................................. 24
8.4 ScanCloseDevice().................................................................................................................. 25
8.5 ScanGetDevInfo() .................................................................................................................. 26
8.6 ScanGetStatus() ..................................................................................................................... 28
April 8, 2010 Page 4 Document#: 6410-00147 K Revision 2.28
Page 5
8.7 ScanRequestDataEvents() ..................................................................................................... 29
8.8 ScanTrigger() ......................................................................................................................... 31
8.9 ScanAbort()............................................................................................................................ 33
8.10 ScanGetData() .......................................................................................................................34
8.11 ScanSetGoodReadSound() ....................................................................................................36
8.12 ScanDeinit() ...........................................................................................................................37
8.13 ScanErrToText() .....................................................................................................................38
8.14 ScanParamSend()................................................................................................................... 39
8.15 ScanParamRequest() .............................................................................................................41
8.16 ScanSendCommand() ............................................................................................................42
8.17 ScanCommandFeature() .......................................................................................................43
8.18 ScanParamSendEx()...............................................................................................................45
8.19 ScanParamRequestEx().......................................................................................................... 47
8.20 IsScannerConnected() ...........................................................................................................48
8.21 IsScannerConnectedEx()........................................................................................................48
8.22 ScanEnableDisableSymbology() ...........................................................................................49
8.23 ScanReadSymbologyConfig() ...............................................................................................50
8.24 ScanWriteSymbologyConfig() ..............................................................................................51
8.25 ScanEnableMultiScanner()....................................................................................................51
8.26 ScanGetScannerRegKey ().....................................................................................................52
8.27 ScanOpenScannerProperty ...................................................................................................53
8.28 ScanCloseScannerProperty ...................................................................................................53
8.29 ScanGetScannerProperty ......................................................................................................53
8.30 ScanSetScannerProperty .......................................................................................................54
8.31 Property identifiers ...............................................................................................................54
8.32 Sample symbology config code:...........................................................................................58
8.32.1 Sample Code to Enable or Disable CODE39 symbology:.........................................58
8.32.2 Sample code for Read configuration: ......................................................................58
8.32.3 Sample Code to Enable or Disable CODE39 symbology:.........................................59
9.0 Cordless Scanner (CS) Specifics......................................................................................................60
9.1 ScanEnableCHS() ...................................................................................................................61
9.2 ScanDisableCHS()................................................................................................................... 62
9.3 ScanSendCmdtoCHS() ...........................................................................................................63
9.4 Bluetooth Connection Status ...............................................................................................65
April 8, 2010 Page 5 Document#: 6410-00147 K Revision 2.28
Page 6
9.5 CHS Commands ..................................................................................................................... 66
9.5.1 Set Security Mode .....................................................................................................66
9.5.2 Set Friendly Name ..................................................................................................... 66
9.5.3 Set PIN Code .............................................................................................................. 66
9.6 CHS Control commands ........................................................................................................ 67
9.6.1 Set Indicators ............................................................................................................. 67
9.6.2 Battery Charge State Inquiry ....................................................................................67
9.6.3 Battery Charge State Response ................................................................................ 67
9.6.4 Friendly Name Inquiry...............................................................................................67
9.6.5 Friendly Name Response...........................................................................................68
9.7 Registry Settings for the Cordless Hand Scanner ................................................................69
10.0 RFID Reader....................................................................................................................................71
11.0 MultiScanner Support (WIN CE ONLY) .........................................................................................72
11.1 Registry Settings for the CF RFID Reader-Scan Card ........................................................... 72
12.0 Using SocketScan (Keyboard Wedge)...........................................................................................74
13.0 SocketScan Trigger Applications (WINCE ONLY) .........................................................................75
13.1 Triggering Details .................................................................................................................76
13.2 Changing the Active Scanner ...............................................................................................77
14.0 The DriverMan dll ..........................................................................................................................78
14.1 Implementing a SocketScan Preview DLL ............................................................................ 79
15.0 Implementing a SocketScan Application in .NET ......................................................................... 81
16.0 Symbology Support by Scanner Type ...........................................................................................82
April 8, 2010 Page 6 Document#: 6410-00147 K Revision 2.28
Page 7
1.0 INTRODUCTION
Note: In this document, the word “scanner” refers to any Socket data collection device, and the word “scan” refers to a bar code scan, RFID read or magnetic stripe read, unless otherwise noted.
The Socket ScanAPI is a set of Windows CE and Win32 Desktop DLLs that offer access to the complete line of data collection products from Socket:
• Secure Digital Scan Card Series 3
• CompactFlash Mag Stripe Reader Card Series 4
• CompactFlash Scan Card Series 5
• CompactFlash RFID Reader Card Series 6
• Socket Bluetooth® Cordless Hand Scanner Series 7
• Socket Bluetooth® Cordless Ring Scanner Series 9
By using the ScanAPI, applications can easily perform the following functions:
• Receive notification of the insertion or removal of a plug-in data collection device or the connection or
disconnection of a wireless data collection device
• Determine the type and properties of data collection devices inserted
• Trigger (and abort) scanning/reading on supported devices that do not have a hardware trigger
• Receive notification of data available from the scanner/reader
• Configure end-user good-read acknowledgement using a beep or by playing a .wav file
Since ScanAPI returns the data block read from the scanner/reader, it is a simple matter for applications to pre-process the data before its final disposition. Applications may add a prefix or a suffix to the data, and perform any other application-specific character translations, insertions or deletions, if desired.
A version of the Socket keyboard wedge software, “SocketScan,” is based on the ScanAPI. It is included in versions for each supported platform on the SDK CD and may also be downloaded from the Socket web site at www.socketmobile.com
• Recognition of the entire line of Socket data collection products
• Flexible addition of prefix and/or suffix to the scanned/read data
• Configuration of a good-read acknowledgement sound
• A “silent mode” allowing VARs to run the wedge software in the background, making it invisible to the
user (for Windows CE only)
• Registry entries allowing VARs to configure the prefix, suffix, sounds, and other properties at install-time
using their own custom installer
• A “Preview DLL” can be registered with the wedge, allowing developers to preview and modify data
scanned by the user
. Its features include:
All binary files for the SocketScan program may be freely distributed by the Developer, for use with Socket data collection products. The documentation supplied is protected via copyrights held by their respective owners and cannot be distributed without written permission.
© Socket Mobile, Inc. October 2, 2008 Page 7 Document#: 6410-00147 J Revision 2.24
Page 8
The term “scanned data” is used throughout this document and generally describes data scanned from a bar code or data returned from reading a RFID tag.
1.1 SDK QUICK START GUIDE
1) Read Chapters 3 and 8 of this User’s Guide to understand the Scanner APIs
2) Read Chapter 5 to understand the sequence of events and messages for the API
3) Based on your requirements, examine the Sample code provided
4) Read Chapter 6 to learn how to trigger your scanner
5) Read Chapter 4 and the Targeted Scanner Deployment document to understand DLL and registry requirements.
You should now be ready to add support for any Socket data collection products to your Windows application.
If needed, please refer to Section 12.2 for a sample of how install your application on the target device.
April 8, 2010 Page 8 Document#: 6410-00147 K Revision 2.28
Page 9
2.0 REVISION NOTES
Although ScanAPI is a thin layer, it is designed for future expansion while also being backwards compatible with existing applications. As new data collection devices with new functionality are supported, the ScanAPI will be expanded to support these new features, while leaving the existing API function interfaces unchanged. Whenever possible, all compatible data collection devices will support the standard ScanAPI mechanism for triggering and retrieving scanned data. This allows devices such as the CF RFID Reader Card to function like a standard bar code scanner even though the RFID reader’s capabilities are more extensive than those of a bar code scanner, with both writing and reading capabilities.
WARNING: Do NOT attempt to change any communication protocol settings or scan any “Set All Defaults” programming bar code with any Socket data collection product unless instructed to do so by Socket Technical Support.
IMPORTANT: ScanAPI currently assumes that the communication parameters for the data collection devices have not been changed from their factory defaults. If the baud rate, word size, etc. have been changed from the factory defaults, they will have to be manually restored before the device will work with ScanAPI. If this happens to the CF Scan Card Series 5 or SD Scan Card Series 3, it must be returned to the factory to restore default communication settings. The SocketScan keyboard wedge program also expects that the attached data collection device has not been programmed to produce prefix or suffix characters.
The SocketScan keyboard wedge application supplied with the SDK offers a powerful feature for developers. A “Preview DLL” can be written and registered with the SocketScan application. This DLL will see the block of scanned data before the data is submitted to the keyboard buffer. This provides the developer an opportunity to validate, pre-process or perform various other modifications on the scanned data. In cases where the keyboard wedge software is very close, but not quite perfect for your custom application’s data collection solution, we believe this new feature may provide many with the opportunity to make it so – quickly, simply and effectively.
If you plan to deploy a large number of data collection devices along with your application, please contact Socket to explore the possibility of having the devices programmed to your specifications during manufacturing. We can ensure that certain symbologies are enabled or disabled, and we can pre-program devices in various other ways to suit your needs.
2.1 WINDOWS CE
This release includes support for Windows CE 4.2 devices up to Windows CE 6.1. The following data collection products are supported:
• Secure Digital Scan Card (SDSC) Series 3
• CompactFlash Mag Stripe Reader Card (MSR) Series 4
• CompactFlash Scan Card (CFSC) Series 5
• CompactFlash RFID Reader Card Series 6
• Socket Bluetooth Cordless Hand Scanner (CHS) Series 7
• Socket Bluetooth Cordless Ring Scanner (CRS) Series 9
2.2 WINDOWS DESKTOP/NOTEBOOK
This release supports the following data collection products for computers running Windows XP Professional/Tablet PC (SP1, SP2, SP3):
• CompactFlash Mag Stripe Reader (MSR) Card Series 4
• CompactFlash Scan Card (CFSC) Series 5
April 8, 2010 Page 9 Document#: 6410-00147 K Revision 2.28
Page 10
• Cordless Hand Scanner (CHS) Series 7
• Cordless Ring Scanner (CRS) Series 9
Full hot-swapping support is present for Windows 7, Vista, and XP.
Note: Use of a CompactFlash card in a Windows 7, Vista or XP based computer requires a CF-to-PC Card adapter, available separately at: http://ww1.socketmobile.com/products/handheld-computers/accessories-hc.aspx?cat=Plug-Ins
Starting from Desktop Release v3.7, SocketScan application support for Win 95, 98, Me and NT platforms has been discontinued. Data collection products may run on these older devices, but compatibility is no longer verified or guaranteed.
April 8, 2010 Page 10 Document#: 6410-00147 K Revision 2.28
Page 11
3.0 USING SCANAPI
The ScanAPI SDK offers API calls that are grouped into the following categories:
The ScanAPI.DLL file is written in C++. This file can only be used in development environments that can directly call Win32 DLLs and process Windows messages. At this time, there is no support for Java.
3.1 SDK INITIALIZATION/DE-INITIALIZATION
• ScanInit() initializes the ScanAPI DLL and allows the client to register for device insertion and
removal messages
• ScanEnableMultiScanner() enables multiple scanners
• ScanDeinit() closes any open scanning devices and performs clean-up in the DLL pending
shutdown
3.2 DEVICE CONTROL
• ScanOpenDevice() opens a scanning device for use
• ScanCloseDevice() closes a scanning device
• ScanGetDevInfo() returns a structure giving device identification and capabilities
• ScanSetGoodReadSound() allows the selection of a sound to be made when the user scans
data
• ScanGetStatus() returns current status of the scanner
• ScanParamSend() modifies a parameter of the scanner (CFSC/SDSC/CHS only)
• ScanParamRequest() retrieves a parameter of the scanner (CFSC/SDSC/CHS only)
• ScanParamSendEx() modifies a 2 byte parameter of the scanner (CFSC/SDSC/CHS only)
• ScanParamRequestEx() retrieves a 2 byte parameter of the scanner (CFSC/SDSC/CHS only)
• ScanSendCommand() sends a command to the CF Scan Card 5X (CF Scan Card 5X only)
• ScanCommandFeature() sends a specific command to use a scanner feature
3.3 SCANNER DATA ACCESS
• ScanRequestDataEvents() allows the client to register for scanned data notifications
• ScanTrigger() initiates a scan (soft-trigger) usually for a scanner with no hardware trigger
(CFSC/SDSC) or a Select Tag for the RFID reader and also works with the CHS/CRS
• ScanAbort() aborts a scan on a TAG read if one is in progress
• ScanGetScannerRegKey() returns the scanner’s active key or driver key
• ScanGetData() retrieves scanned data
3.4 MISCELLANEOUS UTILITY
• ScanErrToText() can be used to translate ScanAPI error codes to human-readable text
• IsScannerConntected() checks whether the scanner is connected and open for
communications
April 8, 2010 Page 11 Document#: 6410-00147 K Revision 2.28
Page 12
• IsScannerConnectedEx() checks whether a specified scanner is connected
3.5 CORDLESS SCANNER SPECIFIC FUNCTIONS
• ScanEnableCHS() activates the Cordless Scanner (CS) and loads its driver
• ScanDisableCHS() deactivates the Cordless Scanner and unloads its driver
• ScanSendCmdtoCHS() sends the Cordless Scanner configuration commands
3.6 RFID SPECIFIC FUNCTIONS
• ScanRFIDSelectTag() selects one or more tags
• ScanRFIDReadTag() reads one or more data blocks from a tag
• ScanRFIDGetData() gets the response and data from a Select, Read, or Write tag command
• ScanRFIDWriteTag() writes one or more data blocks to a tag
• ScanRFIDLockTag() locks one or more blocks on a tag to prevent future writes
April 8, 2010 Page 12 Document#: 6410-00147 K Revision 2.28
Page 13
4.0 SETTING UP THE TARGET DEVICE
Whether you are developing for Window CE or for Win32 Desktop systems, setting up the target device is similar.
4.1 SETTING UP WINDOWS CE DEVICES
On the target CE device, the file ScanAPI.DLL must be present in the \Windows directory. Additionally, you must copy one or more device driver files to the \Windows directory to support the scanning device(s). See the Targeted Scanner Deployment documentation in this SDK for specific information on adding the support files and registry entries for a particular scanner or series of scanner to your target device.
If you install the SocketScan program onto your target CE device, all necessary API and driver files will be installed and configured. SocketScan will run on the Microsoft Windows Mobile 2003 and Windows CE platforms version 4.2 or higher. Before installing SocketScan, uninstall any previously installed scanner software, including the “In-Hand Scanner” program (supplied with the initial shipments of the CF Scan Card) on the target CE device. Also uninstall any legacy versions of the Socket Wand Scanner programs from the target device, if present.
Installing SocketScan will install all the DLLs and set up the proper registry entries, but it should not be used for installing the final user’s application program, because it can confuse the user with unnecessary programs and Icons. The developer should follow the guidelines listed in this SDK guide to can create an installer which will setup only the applications, drivers, and registry entries needed to support the application.
*** It is recommended that SDK users determine exactly which DLLs and registry settings are required for their application rather than using all SocketScan DLLs and settings ***
April 8, 2010 Page 13 Document#: 6410-00147 K Revision 2.28
Page 14
5.0 WRITING YOUR APPLICATION
Applications that use ScanAPI must include the ScanAPI.h file in their project, and must either link to the appropriate ScanAPI.lib file supplied with the SDK or manually load ScanAPI.dll and use GetProcAddress() to access the functions. ScanAPI.h is located in the “inc” directory of the installed SDK. ScanAPI.lib is provided for each supported processor and OS version in the “lib” directory of the installed SDK. The Win32-based sample applications supplied in the SDK are configured with relative include and library paths to find these files when recompiled.
Two windows messages must be defined within the WM_USER range defined by Windows. These messages will be sent to the application when data collection devices are inserted or removed. This document generically refers to these messages as wmInsertion (or WM_INSERTION) and wmRemoval (or WM_REMOVAL). You must also choose a window that will service these messages, typically the main window of your application. Use the window handle and the two messages as arguments to ScanInit(). You must call ScanInit() before using any other ScanAPI function calls except for ScanEnableMultiScanner. Upon a successful call to ScanInit(), your window will begin receiving WM_INSERTION and WM_REMOVAL messages, as appropriate, when a data collection device is inserted or removed from the host device. You will receive a WM_INSERTION immediately if a data collection device is present when the ScanInit() function call is made.
Note: If your application gets a SR_TOO_MANY_USERS error from ScanInit(), you may have ScktScan.exe (keyboard wedge) or another ScanAPI client application running. You will need to close the program before running your ScanAPI application program.
Message handlers must be written for your WM_INSERTION and WM_REMOVAL messages. The WM_INSERTION handler should save the ScanAPI-assigned scanner handle (provided in lParam), then call ScanOpenDevice() using the scanner handle. Upon success, you would use ScanGetDevInfo() if you are interested in the type of scanner that was inserted, and optionally use ScanSetGoodReadSound() if you do not like the default sound, which is to produce a MessageBeep(0) when a successful scan is completed. For multiple devices ScanOpen()/ScanClose() should be called with the appropriate scanner handle.
The message handler for WM_REMOVAL should first check that the scanner handle returned in lParam is, in fact, the handle of the scanner the application is currently aware of, then call ScanCloseDevice(). This release of ScanAPI supports multiple scanners – in this case, multiple WM_INSERTION and WM_REMOVAL message are seen, each with a different scanner handle supplied in lParam. If you do not require multiple scanners there is no need to call ScanEnableMultiScanner(). If an application wants to ignore multiple scanners, it can simply save the handle of the first scanner it sees in a WM_INSERTION message and ignore all other WM_INSERTION messages.
Scanning applications will not be able to receive data until ScanRequestDataEvents() is called. A simple scanning application will define a third windows message, which this document generically refers to as wmScannerData (or WM_SCANNERDATA). This message is supplied along with the handle of the window you want to process this message. The application’s handler for the WM_SCANNERDATA message will take the scanner handle (supplied in lParam) and the size of the data (supplied in wParam), then call ScanGetData(). The data retrieved can then be validated, pre-processed if desired, then sent to an edit control, a list box, or dispatched in any manner the application desires.
A simple application would typically call ScanRequestDataEvents() as part of the WM_INSERTION message handler. Since this registration is nullified whenever the scanning device is closed, it is necessary to call ScanRequestDataEvents() again each time the scanner device is opened.
A more complex application may want to dynamically change the window that will process the WM_SCANNERDATA message, and may even want to change the actual message to be received. This can be done simply by calling ScanRequestDataEvents() again when you want the change to take effect. You can
April 8, 2010 Page 14 Document#: 6410-00147 K Revision 2.28
Page 15
temporarily ignore all scanned data, if desired, by supplying NULL as the hWnd argument to ScanRequestDataEvents().
When your application closes down, it should call ScanDeinit(). This function will close all open scanning devices, making it unnecessary for you to call ScanCloseDevice() when you shut down.
All ScanAPI function calls return SR_SUCCESS if the function succeeds. If a failure occurs, the error returned by the ScanAPI library can be translated to text using the ScanErrToText() function. This function translates the error code into fairly technical jargon and, while this may be useful during software development, the text may not be suitable for display in an end-user application. Since the error messages are located within a string resource that is bound to the ScanAPI DLL file, you may change the wording of these error messages, or translate the messages to different languages if desired, using a resource editing tool.
The Samples directory of the SDK contains several sample programs that can be found in the following subdirectories:
5.1 PREVIEW DLL
This project demonstrates how to create a SocketScan Preview DLL.
5.2 RFID DEMO
This project demonstrates the usage of the RFID-specific API calls.
5.3 SCANAPITESTER
This project demonstrates the usage of the ScanAPI.
5.4 TRIGGERSAMPLE
This application demonstrates how to send a trigger message directly to the ScanAPI library.
5.5 CSHARP SAMPLE
A simple scanning application written using C#.
5.6 COMBO CARD CSHARP SAMPLE
A simple scanning application written using C# that demonstrates the multiple scanner support of ScanAPI when using the CF RFID Reader-Scan Card 6M/6P.
5.7 RFID VB
This Visual Basic based application demonstrates the ScanAPI interfaces to the CF RFID Reader-Scan Card 6M/6P.
5.8 VB SAMPLE
This application demonstrates ScanAPI access from Visual Basic.
April 8, 2010 Page 15 Document#: 6410-00147 K Revision 2.28
Page 16
ActivePairing and Permanent Pair features
The ActivePairing feature works only for Socket Bluetooth barcode scanners. When this feature is activated, ScanAPI listens for an incoming connection from a Socket Bluetooth barcode scanner. The device scans a special barcode which contains the Bluetooth address of the host computer and tries to connect to the host.
If the ActivePairing feature cannot start, a wmInsertion message will be sent by ScanAPI with its wParam set to 1. If this happens, the application should check for this wParam and will not need to open a device if the wParam value is not 0.
In addition to the ActivePairing feature, a Permanent Pair feature can be used in order to have the Socket Bluetooth barcode scanner automatically reconnect to the host computer each time the device is powered on.
The Permanent Pair feature can be turned on by using the new Scanner property APIs ScanOpenScannerProperty, ScanCloseScannerProperty, ScanGetScannerProperty and ScanSetScannerProperty, described later in this document.
The property identifier for the Permanent Pair feature is SCAN_PROP_ID_PERMANENT_PAIR and it accepts a DWORD value that can be 0 to disable Permanent Pair or 1 to enable it.
If a Socket Bluetooth barcode scanner connects to a host computer running ScanAPI that is configured with Permanent Pair enabled, the device will then be permanently paired to this host. Each time the device is powered on, it will try to reconnect to this host.
This permanent pair can be broken by several ways. The first way is to disable the Permanent Pair using the new Scanner property APIs while the device is connected. The second way is to scan a special barcode with the device to reset its operational mode back into acceptor mode. In acceptor mode, the device doesn’t try to connect to any host but instead waits for a host to connect.
April 8, 2010 Page 16 Document#: 6410-00147 K Revision 2.28
Page 17
6.0 SOFT TRIGGERING
Soft triggering differs from local and remote triggering options. It is a means to trigger a scan on a scanner through software; however, this feature is not applicable to all scanners. It is supported in the CFSC, SDSC, CHS, CRS and CF RFID Reader Card. Soft-triggering is enabled within your application via a function key or a button that, when clicked, calls the ScanTrigger() function.
Depending on how your application is designed, some developers may want to assign a hardware button on the host CE device as the trigger, or a function key on Win32 Desktop systems as the trigger, but find it necessary to have this mechanism separate from the application that is directly using the ScanAPI. Since only one executable is allowed to use the ScanAPI at any given time, one way to accomplish this is to write a custom message handler in your application that will handle a WM_SCAN message that you define. The message handler for this WM_SCAN message will call ScanTrigger(). You can then write a very small application that you can assign to one of the hardware buttons on the CE device, or a similar application for the Win32 Desktop environment that hooks the keyboard to detect function key presses. This application should do a FindWindow() to find your application’s main window and send that window your WM_SCAN message.
There is a sample triggering application available in the Utils directory of the SDK. This sample takes the handle of the scanner as a parameter to the executable and can be used to trigger any scanner. It will also work with a .NET application since it sends the message directly to ScanAPI.
The SocketTriggerScan and SocketTriggerRFID applications effectively function as the sample Trigger application with the appropriate preferred handle passed in. Refer to Chapter 13 for more details.
NOTE: SocketTriggerSelect is only used with Socketscan.exe
April 8, 2010 Page 17 Document#: 6410-00147 K Revision 2.28
Page 18
7.0 SCANAPI TYPE REFERENCE
The following excerpts are taken from ScanAPI.h. The brief explanations that follow the excerpts further document the purpose of the identifiers. Refer to the RFID SDK documentation for RFID-specific information.
// Types of Socket Scanner products
enum SCANNER_TYPE {SCANNER_NONE = 0, // no scanner SCANNER_CFCARD, // a CF Scan Card 5E/5M/5P SCANNER_CHS, // a CHS (Cordless Hand Scanner) SCANNER_SDIO, // an SD Scan Card SCANNER_RFID, // an RFID scanner SCANNER_MAG_STRIPE, // a Magnetic Stripe Reader SCANNER_CRS, // a CRS (Cordless Ring Scanner) SCANNER_CF5X // a CF Scan Card 5X };
SCANNER_TYPE is a value that is filled into the ScannerType field of the SCANDEVINFO structure (defined below.) By checking this value, you can determine whether the user has inserted a CF Scan Card, Cordless Hand Scanner, CF RFID Reader Card, etc.
// Types of good-read sounds
enum GRS_TYPE {GRS_NONE = 0, // no good read sound GRS_MESSAGEBEEP, // play MessageBeep(0) on good read GRS_WAVFILE}; // play user-supplied .WAV file on good read
A GRS_TYPE variable is used as an argument when making a call to ScanSetGoodReadSound().
// Scanner device information structure
typedef struct tagSCANDEVINFO{ DWORD StructSize; // size of the structure SCANNER_TYPE ScannerType; // integrated card unsigned int fSoftwareTrigger :1; // most likely an integrated card unsigned int fSoftwareAbortTrigger :1; // most likely an integrated card THCAR SymbolType; // the symbol type (UPC, Code 128, etc.) for last scan } SCANDEVINFO, *LPSCANDEVINFO;
The SCANDEVINFO structure is filled in when it is used in a call to ScanGetDevInfo(). You must fill in the size of the structure, using sizeof(SCANDEVINFO) before calling ScanGetDevInfo(), or an error will result. The rest of the fields have the following meanings:
ScannerType is as defined above. fHardwareTrigger will be TRUE if the device has its own hardware trigger fSoftwareTrigger will be TRUE if calling ScanTrigger() can trigger a scan on the device fSoftwareAbortTrigger will be TRUE if calling ScanAbort() can abort a scan in progress fGoodReadLight will be TRUE if the device has a visual good-read indicator on-board fGoodReadSound will be TRUE if the device makes a sound when data is successfully scanned SymbolType is the code for the last bar code symbol scanned. The value is only valid for the CFSC, SDSC, and CHS, and will be 0x00 if the symbol type is not available. This field is updated when ScanGetData() is called. For a list of bar code values, please refer to the SocketScan Advanced Programming Guide, available online at: www.socketmobile.com/pdf/data-collection/iscprog.pdf
April 8, 2010 Page 18 Document#: 6410-00147 K Revision 2.28
Page 19
// API return codes
enum SCAN_RESULT {SR_SUCCESS = 0, SR_INVALID_WMINSERTION, SR_INVALID_WMREMOVAL, SR_PLUG_THREAD_FAILURE, SR_DEVICE_THREAD_FAILURE, SR_INVALID_SCANNER_HANDLE, SR_OPEN_FAILURE, SR_INVALID_WMSCANNERDATA, SR_NO_DATA, SR_BUFFER_TOO_SMALL, SR_SCANNER_NOT_OPEN, SR_INVALID_SOUND_TYPE, SR_WAVFILE_NOT_FOUND, SR_MEMORY_FAILURE, SR_INVALID_ERR, SR_TOO_MANY_USERS, SR_NOT_INITIALIZED, SR_DEVICE_FAILURE, SR_INTERNAL_FAILURE, SR_INVALID_STRUCTURE, SR_SCANNER_REMOVED, SR_UNSUPPORTED_FEATURE, SR_INVALID_WMCHSSTATUS, SR_NOT_CHS_DEVICE, SR_WAIT_TIMEOUT_ERROR, SR_SYMBOLOGY_NOT_SUPPORTED, SR_SCANNER_BUSY,
SR_HOTSWAP_ERROR, (Windows XP ONLY) SR_SCANNER_REMOVED,
SR_INVALID_WMCHSSTATUS, SR_NOT_CHS_DEVICE, SR_WAIT_TIMEOUT_ERROR, SR_SYMBOLOGY_NOT_SUPPORTED, SR_SCANNER_BUSY, SR_INVALID_WMDIRECTSTATUS
SR_INCOMPATIBLE_VERSION, SR_INVALID_PARAMETERS, SR_NO_ACTIVEPAIRING};
All ScanAPI function calls return SR_SUCCESS if the call was successful. If an error occurs, the return value will be one of the other defined error codes.
Note that SR_HOTSWAP_ERROR is defined in the Win32 Desktop header file only and SR_SCANNER_REMOVED is defined in the WinCE header file only.
Also note that several of the return codes are classified as “failures”:
SR_PLUG_THREAD_FAILURE SR_DEVICE_THREAD_FAILURE SR_OPEN_FAILURE SR_MEMORY_FAILURE SR_DEVICE_FAILURE
April 8, 2010 Page 19 Document#: 6410-00147 K Revision 2.28
Page 20
SR_INTERNAL_FAILURE
If you receive one of these return codes, it means something has gone wrong internally in the ScanAPI DLL, the scanning device has experienced a failure (or unexpected removal), or there are too few resources available on the host device to carry out the request. Any of the first 4 failures listed above may be correctable if the user is asked to close other programs that may be running on the device, thereby freeing up additional resources. A condition that causes SR_DEVICE_FAILURE may be correctable if the user removes the scanner from the device and re-starts your application. SR_INTERNAL_FAILURE is a catch-all for unknown failures that may occur in the ScanAPI DLL. Again, it may be correctable by taking one of the actions already mentioned.
Receiving one of these return codes should be extremely rare. If one of the suggested courses of action does not correct the error condition, the user may be forced to remove the scanner from the CE device and perform a soft reset, or restart the system if the failure has occurred on a Win32 Desktop platform. Please report to Socket Technical Support at http://support.socketmobile.com/
if you consistently receive one of these errors for no good reason – you may be trying to use the API in ways we did not envision when we created it.
April 8, 2010 Page 20 Document#: 6410-00147 K Revision 2.28
Page 21
8.0 SCANAPI FUNCTION REFERENCE
This section provides complete documentation of the functions present in the ScanAPI DLL. Refer to the RFID SDK documentation for information about the RFID-specific functions.
8.1 SCANCHECKVERSION
Prototype:
SCAN_RESULT ScanCheckVersion(DWORD dwVersionAPP,DWORD* pdwVersionAPI,LPCTSTR lpszApplicationName);
Purpose: Performs a version check between the actual version of ScanAPI installed on the host computer and the version of ScanAPI the application has been linked to.
Arguments: [in] dwVersionAPP is the version the application has been linked with. [out] *pdwVersionAPI is the actual ScanAPI version installed on the host computer. [in] lpszApplicationName is the name of the application using ScanAPI.
Notes: If the dwVersionAPP is superior to the actual ScanAPI Version an error would be returned. This error can be ignored if the application developer knows the application can run with this older version of ScanAPI.
Returns: SR_SUCCESS if the Actual ScanAPI version is superior or equal to the version the application has been linked with. SR_INVALID_PARAMETERS if pdwVersionAPI is NULL. SR_INCOMPATIBLE_VERSION if the Actual ScanAPI version is inferior to the version the application has been linked with. The actual ScanAPI version is returned in the *pdwVersionAPI parameter.
April 8, 2010 Page 21 Document#: 6410-00147 K Revision 2.28
Page 22
8.2 SCANINIT()
Prototype:
SCAN_RESULT ScanInit(HWND hWnd, UINT wmInsertion, UINT wmRemoval);
Purpose:
Performs initialization of the ScanAPI DLL and registers the client program to receive device insertion and removal notifications.
Arguments:
[in] hWnd is the handle of the window you want to receive wmInsertion and wmRemoval messages. It is typically the main window of the client program, but it can be any window that is guaranteed to exist for the duration of the client program execution.
If hWnd is 0, no Insertion or Removal Callback events will occur.
[in] wmInsertion is a message within the WM_USER range that the client wants to receive when a Socket data collection device is inserted into the host device.
[in] wmRemoval is a message within the WM_USER range that the client wants to receive when a Socket data collection device is removed from the host device.
Notes:
Upon success, the ScanAPI DLL is initialized. If a Socket data collection device is present when this function is called, the client application will immediately receive the message specified by the wmInsertion argument. If there is no data collection device present when this function is called, the application will receive the wmInsertion message later, when the user inserts a data collection device.
When a client application receives WM_INSERTION or WM_REMOVAL messages, the lParam will contain a scanner handle that must be used to open and close the data collection device, and to perform various other operations on the device with the ScanAPI functions.
If the cordless scanner support mode is turned on, the ActivePairing feature starts as soon as ScanInit has been called, and a wmInsertion will be received to indicate ScanAPI is ready for a Socket cordless data collection device to connect to the host. The wParam of the wmInsertion message contains the success code of the ActivePairing, and a non-zero value means the ActivePairing process failed to start.
This scheme will allow a client application to use multiple data collection devices in future releases of this SDK, though at the present time notifications will be sent only upon the first data collection device insertion and its subsequent removal. If more than one data collection device is present when the SDK is initialized, the SDK will randomly choose one of the devices as being the supported device.
Returns:
SR_SUCCESS The operation completed successfully.
SR_TOO_MANY_USERS
April 8, 2010 Page 22 Document#: 6410-00147 K Revision 2.28
Page 23
In this release of the SDK, only one client may use the ScanAPI DLL. Your application program will generally get this error if ScktScan.exe is running. You need to close the program before starting your application.
SR_INVALID_WMINSERTION The specified wmInsertion message is not within the valid WM_USER range.
SR_INVALID_WMREMOVAL The specified wmRemoval message is not within the valid WM_USER range.
SR_PLUG_THREAD_FAILURE An internal error occurred, most likely due to unavailable resources on the host device. The device will probably need to be reset, though the problem may be correctable if the user terminates other processes on the device and re-tries the operation.
SR_HOTSWAP_ERROR HotSwp32.dll failed to load or initialize. This error is only applicable to Windows 95, 98 or Me host machines. HotSwp32.dll is either missing or corrupt, has not been registered properly, or there are insufficient system resources available to load the DLL. The ScanAPI will not be able to detect card insertion or removal events under these circumstances, so your custom scanning application will be rendered inoperative.
SR_DEVICE_FAILURE May occur as a result of calling ScanInit() on Windows NT systems only. An internal error occurred while communicating with the data collection device (perhaps the device was removed during the function call.) The client application will probably need to be re-started, and possibly the Win32 Desktop system reset (after first removing the data collection device from the host.)
April 8, 2010 Page 23 Document#: 6410-00147 K Revision 2.28
Page 24
8.3 SCANOPENDEVICE()
Prototype:
SCAN_RESULT ScanOpenDevice(HANDLE hScanner);
Purpose:
Opens the scanner port and initializes the scanner for use.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled).
Notes:
Scanners must be opened before being used. Typically a client program will call ScanOpenDevice() as part of the message handler for the WM_INSERTION message (from ScanInit() ).
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
SR_OPEN_FAILURE The ScanAPI DLL was unable to open the device.
SR_DEVICE_THREAD_FAILURE An internal error occurred, most likely due to unavailable resources on the host device. The device will probably need to be reset, though the problem may be correctable if the user terminates other processes on the device and re-tries the operation.
SR_DEVICE_FAILURE An internal error occurred communicating with the scanning device (perhaps the device was removed during the function call.) The client application will probably need to be re-started, and possibly the host CE device or Win32 Desktop system reset (after first removing the scanning device from the host.)
April 8, 2010 Page 24 Document#: 6410-00147 K Revision 2.28
Page 25
8.4 SCANCLOSEDEVICE()
Prototype:
SCAN_RESULT ScanCloseDevice (HANDLE hScanner);
Purpose:
Closes the scanner port and releases resources.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_REMOVAL message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
Notes:
A scanner must be closed if the user removes it during your program’s execution. Typically a client program will call ScanCloseDevice() as part of the message handler of the WM_REMOVAL message.
All open scanners are closed automatically when the ScanDeinit() function is called.
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
April 8, 2010 Page 25 Document#: 6410-00147 K Revision 2.28
Page 26
8.5 SCANGETDEVINFO()
Prototype:
SCAN_RESULT ScanGetDevInfo(HANDLE hScanner, LPSCANDEVINFO lpScanDevInfo);
Purpose: Get the general capabilities and identification of the requested device.
Arguments: [in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
[in/out] lpScanDevInfo is the address of the SCANDEVINFO structure that will receive the information.
Notes:
Client applications may want to know a little about the particular scanning device the user has inserted. For example, if a CHS with a trigger is inserted, the application may want to hide or disable the mechanism it uses to generate a soft-trigger. Additionally, since the CHS has its own good-read feedback (an on-board beeper and LED), the application may want to use ScanSetGoodReadSound() to prevent the ScanAPI DLL from generating additional sounds.
Before calling ScanGetDevInfo(), you must set the StructSize member of your SCANDEVINFO structure to the size of the structure, or the function will fail. Upon successful return, the members of the SCANDEVINFO structure will be filled in with the following information:
• ScannerType will be SCANNER_CFCARD (for a CF Scan Card), SCANNER_SDIO (for the SDSC), or
SCANNER_CHS (for the CHS).
• fHardwareTrigger will be TRUE if the device has its own hardware trigger
• fSoftwareTrigger will be TRUE if calling ScanTrigger() can trigger a scan on the device
• fSoftwareAbortTrigger will be TRUE if calling ScanAbort() can abort a scan in progress
• fGoodReadLight will be TRUE if the device has a visual good-read indicator on-board
• fGoodReadSound will be TRUE if the device makes a sound when data is successfully scanned
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
SR_SCANNER_NOT_OPEN This function fails if the scanner is not open.
April 8, 2010 Page 26 Document#: 6410-00147 K Revision 2.28
Page 27
SR_INVALID_STRUCTURE The lpScanDevInfo argument was NULL or the StructSize field was not set with the sizeof(SCANDEVINFO) value when the function call was made.
SR_DEVICE_FAILURE An internal error occurred communicating with the scanning device (perhaps the device was removed during the function call.) The client application will probably need to be re-started, and possibly the host CE device or Win32 Desktop system reset (after first removing the scanning device from the host.)
April 8, 2010 Page 27 Document#: 6410-00147 K Revision 2.28
Page 28
8.6 SCANGETSTATUS()
Prototype:
SCANAPI_API SCAN_RESULT ScanGetStatus(HANDLE hScanner);
Purpose: Get the current status of the scanner and device driver. This API call was added so an application program could query the scanner to determine if scanner data was available or the general state of the scanner (scanner inserted/removed).
For the RFID reader, this function works with both legacy (ScanTrigger) and RFID-specific functions.
Arguments: [in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, hard coding the value of 1 will return the proper status.
Returns:
SR_SUCCESS Indicates the scanner is in place and scanned data is available in the buffer. Call ScanGetData() to retrieve the data.
SR_NOT_INITIALIZED The scanner has not been initialized. A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle. This indicates there is no scanner present or the handled supplied is not correct.
SR_SCANNER_NOT_OPEN The scanner is present but ScanOpenDevice() has not been called.
SR_NO_DATA There is no data available from the scanning device.
SR_SCANNER_REMOVED The scanner has been removed from the socket. A call to ScanCloseDevice() should be made.
April 8, 2010 Page 28 Document#: 6410-00147 K Revision 2.28
Page 29
8.7 SCANREQUESTDATAEVENTS()
Prototype:
SCAN_RESULT ScanRequestDataEvents(HANDLE hScanner, HWND hWnd, UINT wmScannerData);
Purpose:
Instruct ScanAPI to send a message to the client application when the user has scanned data.
Arguments:
[in] hScanner is the value received by the client application in the lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
[in] hWnd is the handle of the window in the client application that will process the WM_SCANNERDATA message.
This value must be non-0 (null) in order for SocketScan to store scanned data in the buffer. This is true even if the application doesn’t accept callback events.
[in] wmScannerData is a message defined by the client application that will be sent whenever the user successfully scans data.
This message must be within the WM_USER range in order for SocketScan to store scanned data in the buffer. This is true even if the application doesn’t accept callback events
Notes:
The client application must call the ScanGetData() API in response to receiving a WM_SCANNERDATA message. When WM_SCANNERDATA is received by the client application, lParam will contain the scanner handle and wParam will contain the size of the data available in bytes. This can be converted into a character count (if desired) by dividing the size of the data by the sizeof(TCHAR). Typically the size of the data in bytes will equal the character count when running on Win32 Desktop systems.
Only one window at a time can be notified of the arrival of scanned data. Subsequent calls to ScanRequestDataEvents() simply change the desired window and/or user message to be sent. To disable data notifications altogether, call ScanRequestDataEvents() using NULL as the hWnd argument.
See ScanGetStatus() for information on using ScanAPI without messages.
It is up to the developer to decide where scanned data should be routed. The simplest approach is to let the main window receive all WM_SCANNERDATA notifications and have it deal with the data (by calling ScanGetData() and routing the data to the desired control). Another more complex but valid approach is to add handlers for WM_SCANNERDATA to numerous windows. Then the application can call ScanRequestDataEvents() with different hWnd arguments (and possibly different wmScannerData arguments) when necessary in the WM_ACTIVATE handlers of these windows. Then each window could process the scanned data in different ways, if necessary.
If hWnd or wmScannerData parameters are 0, no client message is sent when scanned data is received and no scanner data is stored in the buffer. An application program can use this feature to enable/disable scanning depending upon where the keyboard focus is within the application.
April 8, 2010 Page 29 Document#: 6410-00147 K Revision 2.28
Page 30
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
SR_INVALID_WMSCANNERDATA The wmScannerData argument is not within the valid WM_USER range.
April 8, 2010 Page 30 Document#: 6410-00147 K Revision 2.28
Page 31
8.8 SCANTRIGGER()
Prototype:
SCAN_RESULT ScanTrigger(HANDLE hScanner);
Purpose:
Trigger a scan on a scanning device.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
Notes:
For the CFSC/SDSC/CHS, this function returns immediately and, upon a successful read, the client application will receive the user-defined WM_SCANNERDATA message specified in a prior call to ScanRequestDataEvents(). For scanners that use hardware triggers on the scanner device, this function returns successfully but has no effect. For these other devices, the client application will asynchronously receive the WM_SCANNERDATA message when the user presses the trigger button on the scanner.
Normally, this call is used start the scanner. The scanning stops after scanning a supported bar code or when the time-out period expires (typically 3 seconds). There is no indication to the calling program if no bar code is found.
For RFID, this call will issue a Select Tag command to the reader – depending on registry settings this can be modified. This call is made with tag type set to Auto-detect so it returns the first tag ID it can read in its field. The application program will receive a WM_SCANNERDATA message indicating data is available and calling ScanGetData() returns the tag type and tag ID. No message will be received if there is no tag in the field at the time ScanTrigger() is called or if there was an error reading the tag. Note that this behavior is dependent on the settings found in the registry or modified via the RFID Setup Control Panel.
Note: This is a legacy function for compatibility with SocketScan and it’s recommended that ScanRFIDSelectTag() be used instead.
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
SR_SCANNER_NOT_OPEN This function fails if the scanner is not open.
April 8, 2010 Page 31 Document#: 6410-00147 K Revision 2.28
Page 32
SR_DEVICE_FAILURE An internal error occurred communicating with the scanning device (perhaps the device was removed during the function call.) The client application will probably need to be re-started, and possibly the host CE device reset or the Win32 Desktop system restarted (after first removing the scanning device from the host.)
April 8, 2010 Page 32 Document#: 6410-00147 K Revision 2.28
Page 33
8.9 SCANABORT()
Prototype:
SCAN_RESULT ScanAbort(HANDLE hScanner);
Purpose:
Terminate a scan-in-progress on a scanning device.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
Notes:
For scanning devices that support this operation, the laser beam is switched off and the scan is terminated. Calling this function when a scan is not in progress or on devices that do not support this feature, has no effect and the function returns successfully. This function not implemented for the CF Scan Card 5X.
For RFID this function aborts any “loop” mode operation started by the ScanRFIDSelectTag() function.
It may also be used to abort any pending RFID response/data indicated by a WM_SCANNERDATA message if ScanRFIDGetData() function is not called. (The application must call ScanRFIDGetData() for every WM_SCANNERDATA message received unless ScanAbort() is called.)
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
SR_SCANNER_NOT_OPEN This function fails if the scanner is not open.
SR_DEVICE_FAILURE An internal error occurred communicating with the scanning device (perhaps the device was removed during the function call.) The client application will probably need to be re-started, and possibly the host CE device reset, or Win32 Desktop system restarted (after first removing the scanning device from the host.)
April 8, 2010 Page 33 Document#: 6410-00147 K Revision 2.28
Page 34
8.10 SCANGETDATA()
Prototype:
SCAN_RESULT ScanGetData(HANDLE hScanner, TCHAR * lpBuff, LPINT BufSize);
Purpose:
Returns scanned data after a successful read operation on the scanner device.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
[out] lpBuff points to the buffer to receive the scanned data.
[in/out] BufSize points to the size of the buffer in bytes (not characters). Upon return, BufSize will be set to the number of bytes written into lpBuff. This can be converted to a character count by dividing BufSize by sizeof(TCHAR). Typically the buffer size will be equal to the character count on Win32 Desktop systems.
Notes:
ScanGetData() should be called in response to receiving the WM_SCANNERDATA message. The data returned will be in UNICODE on CE devices.
It is possible for NULL characters to appear in the scanned data, depending on the symbology scanned by the user. Also note that the ScanAPI DLL will not NULL-terminate the scanned data. Therefore, do all necessary validity checks on the buffer before you do anything with the data. Once the data is validated, you can add your own prefix or suffix, add your own terminating NULL, or perform any other pre-processing to the data stream you desire.
To discover the size of the data available without actually retrieving it from the scanner, you may use NULL as the lpBuff argument – in this case BufSize will be filled in with the size of the data and the function will return successfully. If lpBuff is not NULL and the buffer is too small, no data transfer will take place, the size of the buffer necessary will be written to BufSize, and the function will return SR_BUFFER_TOO_SMALL. At this point you MUST call ScanGetData() again with a larger buffer to remove the data and allow for continued scanning.
Applications should respond to the WM_SCANNERDATA message as soon as possible. The ScanAPI DLL has a small buffer for storing multiple scans (currently 16 scans), in case the user is scanning data more quickly than your application can process it. But when this buffer fills, additional scanned data will be discarded, and no notifications of the overflowed data will be sent.
If the application program doesn’t accept callback events, calling ScanGetStatus() will return status of the scanner along with data available status.
For RFID this function is called to get the tag ID as a result of a ScanTrigger() call. The data is returned is one of TagID, Tag Data, or TagID and Tag Data. For example it could return just the TagID as an ASCII string containing the tag type followed by a “:” and the tag ID.
As an example, an ISO 15693 tag with an ID of E007000001476301, would be returned in 19 bytes as:
April 8, 2010 Page 34 Document#: 6410-00147 K Revision 2.28
Page 35
“01:E007000001476301”
Note: This is a legacy function for compatibility with SocketScan and it’s recommended that the specific RFID functions be used instead of ScanTrigger() and ScanGetData(). Do not call this function when issuing any specific RFID function (i.e. ScanRFIDSelectTag(), ScanRFIDReadTag(), etc.).
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
SR_SCANNER_NOT_OPEN This function fails if the scanner is not open.
SR_NO_DATA There is no data available from the scanning device.
SR_BUFFER_TOO_SMALL A larger buffer is required to accommodate the data from the scanner.
The user MUST call ScanGetData() again with a larger buffer to remove the data and allow for continued scanning.
April 8, 2010 Page 35 Document#: 6410-00147 K Revision 2.28
Page 36
8.11 SCANSETGOODREADSOUND()
Prototype:
SCAN_RESULT ScanSetGoodReadSound(HANDLE hScanner, GRS_TYPE Sound, LPCTSTR lpWavFile);
Purpose:
Tells the ScanAPI DLL to be silent, call MessageBeep(0), or play a .wav file when the user successfully scans data with the specified device.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
[in] Sound is GRS_NONE, GRS_MESSAGEBEEP, or GRS_WAVFILE.
[in] lpWavFile points to the full path and filename of a .wav file to play.
Notes: There is no corresponding function to return the current settings for a device. When a scanning device is opened, the default configuration is for a MessageBeep(0) to be executed on a good read. Applications will probably want to call ScanSetGoodReadSound() immediately after successfully opening the scanner with ScanOpenDevice() in the WM_INSERTION message handler, if the default sound configuration is not desired.
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_INVALID_SCANNER_HANDLE The hScanner argument is not a valid scanner handle.
SR_INVALID_SOUND_TYPE The Sound argument must be GRS_NONE, GRS_MESSAGEBEEP, or GRS_WAVFILE.
SR_WAVFILE_NOT_FOUND Unable to find the file referenced by the lpWavFile argument.
SR_MEMORY_FAILURE An internal error occurred, most likely due to unavailable resources on the host device. The device will probably need to be reset, though the problem may be correctable if the user terminates other processes on the device and re-tries the operation.
April 8, 2010 Page 36 Document#: 6410-00147 K Revision 2.28
Page 37
8.12 SCANDEINIT()
Prototype:
SCAN_RESULT ScanDeinit();
Purpose:
Performs final clean-up in the DLL pending shutdown.
Arguments:
None.
Notes:
ScanDeinit() is typically called during the shutdown/cleanup phase of the client application. Any scanning devices that are open will be closed by the ScanDeinit() function.
Returns:
SR_SUCCESS The operation completed successfully.
SR_NOT_INITIALIZED A successful call to ScanInit() must be made first.
SR_DEVICE_FAILURE May occur as a result of calling ScanInit() on Windows NT systems only. An internal error occurred while communicating with the scanning device (perhaps the device was removed during the function call.) The client application will probably need to be re-started, and possibly the Win32 Desktop system reset (after first removing the scanning device from the host.)
On Windows NT systems, a scanning device MUST be present in the system BEFORE calling ScanInit(). Additionally, the scanning device MUST NOT BE REMOVED from the system while the ScanAPI is in use. Since the API does not support hot-swapping for this platform, no device removal or insertions messages are generated. If a card is removed and re-inserted while a scanning session is in progress, the COM port associated with the PC Card will not be configured properly, and ScanAPI errors will result.
Under Windows NT, all PC Card devices must be present at boot-time, and can never be safely removed without re-booting. The exception is if you have added third-party Card and Socket Services to your NT system. In this case, the scanning device must be present before the ScanInit() call, but can be safely removed AFTER ScanDeinit() is called.
April 8, 2010 Page 37 Document#: 6410-00147 K Revision 2.28
Page 38
8.13 SCANERRTOTEXT()
Prototype:
SCAN_RESULT ScanErrToText(SCAN_RESULT Err, LPTSTR lpBuff, LPINT BufSize);
Purpose:
Converts error code to text.
Arguments:
[in] Err is the error generated by a ScanAPI function call that you wish to have translated to text.
[out] lpBuff is a buffer allocated by the client program to receive the text. Note the result is returned in UNICODE on CE devices.
[in/out] BufSize points to an integer that must be set to the size of lpBuff before the ScanErrToText() function is called – it will be filled in by the SDK with the size of the error text (in bytes) upon return. This value can be converted to a character count by dividing BufSize by the sizeof(TCHAR). Typically the byte count will equal the character count on Win32 Desktop systems.
Notes:
To discover the size of the error text without actually retrieving it, you may use NULL as the lpBuff argument – in this case BufSize will be filled in with the size of the error message and the function will return successfully. If lpBuff is not NULL and the buffer is too small, no data transfer will take place, the size of the buffer necessary will be written to BufSize, and the function will return SR_BUFFER_TOO_SMALL.
Returns:
SR_SUCCESS The operation completed successfully.
SR_INVALID_ERR The error you are trying to translate is not known.
SR_BUFFER_TOO_SMALL A larger buffer is required to accommodate the text.
SR_INTERNAL_FAILURE An unexpected error occurred in the ScanAPI DLL.
April 8, 2010 Page 38 Document#: 6410-00147 K Revision 2.28
Page 39
8.14 SCANPARAMSEND()
Prototype:
SCANAPI_API SCAN_RESULT ScanParamSend(HANDLE hScanner, PBYTE paramIn, UINT paramInLen, PBYTE paramVal, UINT paramValLen);
Purpose:
Modifies one or more parameters of the scanner hardware for WinCE only.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks, use 1 for the HANDLE (if multi-scanner disabled) .
[in] paramIn is a byte buffer containing one or more parameter numbers that will be modified.
[in] paramInLen is the length of the paramIn buffer in bytes.
[in] paramVal is a buffer containing the values that will be used when changing the parameters specified by the paramIn buffer. All parameter values are bytes but the paramVal buffer may be arranged as 8-bit or 16-bit values -- see notes below for important information on the composition of the paramVal buffer.
[in] paramValLen is the size in bytes of the paramVal buffer.
Notes:
This function is only supported by the CFSC, SDSC and CHS scanners (not the CF Scan Card 5X.) Executing this function on other scanners will return ERROR_NOT_SUPPORTED.
The CFSC/SDSC/CHS scanners support two modes for setting scanner parameters. In the first mode, temporary mode, the parameter changes will be in effect only as long as the scanner is powered (inserted in the CF slot with the device powered on). Once power is removed, the parameter(s) will revert to its previous value. In the second mode, permanent mode, the parameter changes are permanent and will remain in effect until changed via another ScanParamSend call.
The default behavior of the ScanParamSend call is to make changes in temporary mode. To use this mode, simply create a buffer of 8-bit values for the paramVal parameter.
To make changes in permanent mode, create the paramVal buffer as an array of 16-bit (USHORT) values. Place the desired parameter value in the lower 8-bits and set the upper bit (bit 15) to 1. Note that only the upper bit of the first parameter element of the buffer must be set to enable permanent mode. Set the paramValLen parameter to be the length of the paramVal buffer which in permanent mode is twice number of parameters (sizeof(USHORT) * sizeof(paramIn)).
Refer to the SocketScan Advanced Programming Guide for a list of parameter settings. See the sample source code for an example.
Returns:
SR_SUCCESS The operation completed successfully.
April 8, 2010 Page 39 Document#: 6410-00147 K Revision 2.28
Page 40
ERROR_NOT_SUPPORTED The scanner in use does not support the ScanParamSend function.
ERROR_NOT_READY A problem occurred sending the command(s) to the scanner.
ERROR_OUTOFMEMORY The function was not able to allocated memory needed to complete the request.
April 8, 2010 Page 40 Document#: 6410-00147 K Revision 2.28
Page 41
8.15 SCANPARAMREQUEST()
Prototype:
SCAN_RESULT ScanParamRequest(HANDLE hScanner, PBYTE paramIn, UINT paramInLen, PBYTE paramOut, PUINT paramOutLen);
Purpose:
Retrieves the current setting of one parameter of the scanner hardware for WinCE only
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks , use 1 for the HANDLE (if multi-scanner disabled) .
[in] paramIn is a byte buffer containing the parameter number that will be retrieved.
[in] paramInLen is the length of the paramIn buffer in bytes (should always be 1).
[out] paramOut is a byte buffer that will contain the value of the requested parameter.
[in/out] paramOutLen is the size in bytes of the paramOut buffer. This should be set to 1 when calling ScanParamRequest. Upon exit, this will be set to 0 if an error occurs, 1 otherwise.
Notes:
This function is only supported by the CFSC/SDSC/CHS (not the CF Scan Card 5X). Executing this function on other scanners will return ERROR_NOT_SUPPORTED.
Currently, only one parameter at a time can be retrieved via the ScanParamRequest function.
Refer to the
Returns:
SR_SUCCESS The operation completed successfully.
ERROR_NOT_SUPPORTED The scanner in use does not support the ScanParamSend function.
ERROR_NOT_READY An internal error occurred requesting the parameter from the scanner.
ERROR_INSUFFICIENT_BUFFER The length of the paramOut buffer was not 1.
Advanced Programming Guide
for a list of parameter settings.
April 8, 2010 Page 41 Document#: 6410-00147 K Revision 2.28
Page 42
8.16 SCANSENDCOMMAND()
Prototype:
SCANAPI_API SCAN_RESULT ScanSendCommand(HANDLE hScanner, IN OUT LPTSTR pCmd_CmdResponse, IN OUT int* piLength);
Purpose:
Sends a command to the CF Scan Card hardware and receives the CF Scan Card response for WinCE only.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks , use 1 for the HANDLE (if multi-scanner disabled) .
[in out] pCmd_CmdResponse is a TCHAR buffer containing the command to be sent. It also receives the response to the command by the imager.
[in out] piLength is an integer that specifies the maximum number of characters pCmd_CmdResponse buffer can hold. It also receives the number of bytes returned in the pCmd_CmdResponse.
Notes:
This function is only supported by the CF Scan Card 5X. Executing this function on other scanners will return ERROR_NOT_SUPPORTED.
Currently, only one command at a time can be sent via the ScanSendCommand function.
Refer to the SocketScan Advanced Programming Guide for a list of commands.
Returns:
SR_SUCCESS The operation completed successfully.
SR_UNSUPPORTED_FEATURE The scanner in use does not support the ScanSendCommand function.
SR_INTERNAL_FAILURE An internal error occurred requesting the parameter from the scanner.
SR_BUFFER_TOO_SMALL The length of the pCmd_CmdResponse was insufficient to hold the entire response.
April 8, 2010 Page 42 Document#: 6410-00147 K Revision 2.28
Page 43
8.17 SCANCOMMANDFEATURE()
Prototype:
SCANAPI_API SCAN_RESULT ScanCommandFeature(HANDLE hScanner,eCommandID nCommandId, CommandFeature_t* pCommandFeature);
Purpose:
This API enables a feature of ScanAPI or the scanner. It has been originally created to handle the RFID AFI feature.
The RFID AFI feature is supported only for the tag ISO 15693 and with the Socket hardware that has a firmware version 3005 or higher. The AFI feature is composed by a set of three functions. Read AFI that reads an AFI value of a tag specified by its tag ID and tag type. Write AFI writes a specific AFI value to the tag matching to the tag ID and tag type. The Lock AFI has to be used with caution as this operation is irreversible. It locks an AFI value to a tag specified with the tag ID and tag type. The tag will have the specified AFI value for ever.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called that represents a handle to a scanner.
[in] eCommandID nCommandId is an enumerator containing the command identifier to be sent. The current identifiers available are:
- CMDID_READ_RFID_AFI: Read RFID AFI out of an RFID tag, the AFI is returned in dwRfidAfi
member of the CommandFeature_t structure.
- CMDID_WRITE_RFID_AFI: Write RFID AFI into a RFID tag,
- CMDID_LOCK_RFID_AFI: Lock RFID AFI into a RFID tag.
[in out] CommandFeature_t* pCommandFeature is a pointer to a structure. This parameter is used as in or/and out parameter.
The CommandFeature_t structure has the following members:
- dwStructSize: this member should contain the actual size of the structure
- dwRfidAfi: this member contains the AFI code. This field is applicable only for RFID scanner
- dwRfidTagType: this member contains the tag type of a RFID tag. The type supporting the AFI
feature is either 0 for AUTO DETECT TAG TYPE of 1 for TAG TYPE ISO15693.
- pucRfidTagId[16]: this 16 bytes member contains the Tag ID (usually 10 bytes long) . For Tag
Type ISO15693 the first 10 bytes are used.
- dwRfidTagIdLength: this field contains the actual length of the TAG ID.
This API is blocked and in the case of a READ AFI operation, the response will be store in the CommandFeature_t structure pointed by pCommandFeature input/output parameter.
Returns:
SR_SUCCESS The operation completed successfully. In the case of a Read AFI command, the AFI value is returned in the dwRfidAfi field of the CommandFeature_t structure.
SR_INVALID_PARAMETERS The operation could not be completed as at least one of the parameter passed in input is incorrect because one of the following statement is true:
April 8, 2010 Page 43 Document#: 6410-00147 K Revision 2.28
Page 44
- the CMD_ID is not unknown,
- the dwRfidTagIdLength is bigger than MAX_TAG_ID_SIZE (10 bytes)
SR_INVALID_STRUCTURE The operation could not be completed as the size of the CommandFeature_t structure doesn’t correspond to the size specified in the dwStructSize of the same structure.
SR_UNSUPPORTED_FEATURE The scanner in use does not support the ScanCommandFeature function.
SR_INTERNAL_FAILURE An internal error occurred requesting the parameter from the scanner.
SR_NOT_INITIALIZED The ScanAPI is not initialized correctly by using the ScanInit API.
SR_INVALID_SCANNER_HANDLE The hScanner value is invalid.
SR_SCANNER_NOT_OPEN The hScanner is an handle to a scanner that has not be opened using ScanOpenDevice API.
SR_DEVICE_FAILURE An error occurs in the Scanner protocol driver.
April 8, 2010 Page 44 Document#: 6410-00147 K Revision 2.28
Page 45
8.18 SCANPARAMSENDEX()
Prototype:
SCANAPI_API SCAN_RESULT ScanParamSendEx(HANDLE hScanner, PUINT16 paramIn, UINT paramInLen, PBYTE paramVal, UINT paramValLen);
Purpose:
Modifies one or more parameters of the scanner hardware. This API is slightly different from ScanParamSend() in that the ‘paramIn’ is now of type PUINT16. This is for opcodes that are of two byte lengths (i.e. RSS-14) and is for WinCE only.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
If the application program doesn’t support callbacks , use 1 for the HANDLE (if multi-scanner disabled) .
[in] paramIn is a 16 bit buffer containing one or more parameter numbers that will be modified.
[in] paramInLen is the length of the paramIn buffer in bytes.
[in] paramVal is a buffer containing the values that will be used when changing the parameters specified by the paramIn buffer. All parameter values are bytes but the paramVal buffer may be arranged as 8-bit or 16-bit values -- see notes below for important information on the composition of the paramVal buffer.
[in] paramValLen is the size in bytes of the paramVal buffer.
Notes:
This function is only supported by the CFSC, SDSC or CHS (not the 2DSC). Executing this function on other scanners will return ERROR_NOT_SUPPORTED.
The CFSC/SDSC/CHS support two modes for setting scanner parameters. In the first mode, temporary mode, the parameter changes will be in effect only as long as the scanner is powered (inserted in the CF slot with the device powered on). Once power is removed, the parameter(s) will revert to its previous value. In the second mode, permanent mode, the parameter changes are permanent and will remain in effect until changed via another ScanParamSend call.
The default behavior of the ScanParamSend call is to make changes in temporary mode. To use this mode, simply create a buffer of 16-bit values for the paramVal parameter.
To make changes in permanent mode, create the paramVal buffer as an array of 16-bit (USHORT) values. Place the desired parameter value in the lower 8-bits and set the upper bit (bit 15) to 1. Note that only the upper bit of the first parameter element of the buffer must be set to enable permanent mode. Set the paramValLen parameter to be the length of the paramVal buffer which in permanent mode is twice number of parameters (sizeof(USHORT) * sizeof(paramIn)).
Refer to the See the sample source code for an example.
Returns:
Advanced Programming Guide
for a list of parameter settings.
April 8, 2010 Page 45 Document#: 6410-00147 K Revision 2.28
Page 46
SR_SUCCESS The operation completed successfully.
SR_UNSUPPORTED_FEATURE The scanner in use does not support the ScanParamSendEx function.
SR_DEVICE_FAILURE A problem occurred sending the command(s) to the scanner.
April 8, 2010 Page 46 Document#: 6410-00147 K Revision 2.28
Page 47
8.19 SCANPARAMREQUESTEX()
Prototype:
SCANAPI_API SCAN_RESULT ScanParamRequestEx(HANDLE hScanner, PUINT16 paramIn, UINT paramInLen, PBYTE paramOut, PUINT paramOutLen);
Purpose:
Retrieves the current setting of one parameter of the scanner hardware. This API is slightly different from ScanParamRequest() in that the ‘paramIn’ is now of type PUINT16. This is for opcodes that are of two byte lengths (i.e. RSS-14).
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
[in] paramIn is a 16 bit buffer containing the parameter number that will be retrieved.
[in] paramInLen is the length of the paramIn buffer in bytes (should always be 1).
[out] paramOut is a byte buffer that will contain the value of the requested parameter.
[in/out] paramOutLen is the size in bytes of the paramOut buffer. This should be set to 1 when calling ScanParamRequest. Upon exit, this will be set to 0 if an error occurs, 1 otherwise.
Notes:
This function is not supported by the CF Scan Card 5X. Executing this function on scanners other than CFSC/SDSC/CHS will return ERROR_NOT_SUPPORTED.
Currently, only one parameter at a time can be retrieved via the ScanParamRequestEx function.
Refer to the
Returns:
SR_SUCCESS The operation completed successfully.
SR_UNSUPPORTED_FEATURE The scanner in use does not support the ScanParamSendEx function.
SR_DEVICE_FAILURE An internal error occurred requesting the parameter from the scanner.
SR_BUFFER_TOO_SMALL The length of the paramOut buffer was not 1.
Advanced Programming Guide
for a list of parameter settings.
April 8, 2010 Page 47 Document#: 6410-00147 K Revision 2.28
Page 48
8.20 ISSCANNERCONNECTED()
Prototype:
SCANAPI_API BOOL IsScannerConnected (void)
Purpose:
Checks if the scanner is connected and is open for communication.
Arguments:
No arguments
Returns:
TRUE The scanner is connected and is open for communications
FALSE If scanner has an invalid handle or is not OPEN.
8.21 ISSCANNERCONNECTEDEX()
Prototype:
SCANAPI_API BOOL IsScannerConnectedEx (SCANNER_TYPE scannerType)
Purpose:
To determine if either a scanner is connected or a particular type of scanner is connected in a multi-scanner scenario. IsScannerConnected() calls this API with SCANNER_NONE as a parameter.
Arguments:
[in] scannerType: Type of scanner to check
Returns:
TRUE The scanner is connected and is open for communications
FALSE If scanner has an invalid handle or is not OPEN.
April 8, 2010 Page 48 Document#: 6410-00147 K Revision 2.28
Page 49
8.22 SCANENABLEDISABLESYMBOLOGY()
Prototype:
SCANAPI_API SCAN_RESULT ScanEnableDisableSymbology (HANDLE hScanner, INT nSymID, BOOL flag);
Purpose:
Enables or Disables symbologies for all types of Socket bar code scanner devices.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
[in] nSymID is the symbology ID to be Enabled or Disabled. For symbology IDs refer to the enumerated data type SCANNER_SYMBOLOGY in SCANAPI.h file.
[in] flag to enable or disable symbology
Returns:
SR_SUCCESS The operation completed successfully
SR_INVALID_SCANNER_HANDLE Invalid scanner handle
SR_SYMBOLOGY_NOT_SUPPORTED Invalid symbology ID
SR_DEVICE_FAILURE An internal error occurred requesting a call to the scanner
NOTE: This API will supersede ScanParamSend(), ScanParamSendEx() API calls.
April 8, 2010 Page 49 Document#: 6410-00147 K Revision 2.28
Page 50
8.23 SCANREADSYMBOLOGYCONFIG()
Prototype:
SCANAPI_API SCAN_RESULT ScanReadSymbologyConfig (HANDLE hScanner, int cfgType, int nSymbol, PVOID pvSym);
Purpose:
Reads symbology configuration for all types of Socket bar code scanner devices
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
[in] cfgType is the configuration type to read the CURRENT or DEFAULT configuration of the symbology
[in] nSymbol is the symbology ID to read the configuration. For symbology IDs refer to the enumerated data type SCANNER_SYMBOLOGY in SCANAPI.h file
[in] pvSym is the void pointer to the structure with that has structure size, mask and that will contain symbology info on return
Returns:
SR_SUCCESS The operation completed successfully
SR_INVALID_SCANNER_HANDLE Invalid scanner handle
SR_INVALID_ERR Invalid structure passed to read the symbology configuration
SR_SYMBOLOGY_NOT_SUPPORTED Invalid symbology ID
SR_DEVICE_FAILURE An internal error occurred requesting a call to the scanner to Enable/Disable symbology
NOTE: This API will supersede ScanParamRequest(), ScanParamRequestEx() API calls.
© Socket Communications, Inc. November 16, 2004 Revision 2.18
Page 51
8.24 SCANWRITESYMBOLOGYCONFIG()
Prototype:
SCANAPI_API SCAN_RESULT ScanWriteSymbologyConfig (HANDLE hScanner, int nSymbol, PVOID pvSym);
Purpose:
Writes symbology configuration for all types of Socket bar code scanner devices
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
[in] nSymbol is the symbology ID to write the configuration to. For Symbology IDs refer to the enumerated data type SCANNER_SYMBOLOGY in SCANAPI.h file.
[in] pvSym is the void pointer to the structure that has symbology configuration settings
Returns:
SR_SUCCESS The operation completed successfully
SR_INVALID_SCANNER_HANDLE Invalid scanner handle
SR_UNSUPPORTED_FEATURE Is returned if any scanner other than the CF Scan Card 5X tries to set configuration parameters
SR_SYMBOLOGY_NOT_SUPPORTED Invalid symbology ID
SR_DEVICE_FAILURE An internal error occurred requesting a call to the scanner to Enable/Disable symbology
NOTE: This API will supersede ScanParamSend(), ScanParamSendEx() API calls.
8.25 SCANENABLEMULTISCANNER()
Prototype:
SCANAPI_API SCAN_RESULT ScanEnableMultiScanner(void);
Purpose:
This function must be called before ScanInit() by the application in order to enable multiple scanners.
Arguments:
None
© Socket Communications, Inc. November 16, 2004 Revision 2.18
Page 52
Returns:
SR_SUCCESS The operation completed successfully
SR_INVALID_ERR The scanner was already initialized
SR_NOT_INITIALIZED The Scanning library is not initialized
SR_INVALID_SCANNER_HANDLE Scanner handle is not valid
SR_SCANNER_NOT_OPEN Scanner is not open
8.26 SCANGETSCANNERREGKEY ()
Prototype:
SCANAPI_API SCAN_RESULT ScanGetScannerRegKey(HANDLE hScanner, BOOL activeKey, LPTSTR lpBuff, LPINT BufSize);
Purpose: This returns a path to the key of the active device in order to extract parameters for that device from the registry
Arguments: [in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
[in] activeKey
[in/out] lpBuff contains the registry key
[in/out] BufSize contains the size of the string (including terminating zero) in bytes
Returns: If activeKey is TRUE, the scanner's active key (\Drivers\Active\NN) key string will be returned, otherwise it returns the driver key (\Drivers\PCMCIA\PnP ID\etc).
SR_INVALID_ERR The scanner was already initialized
SR_NOT_INITIALIZED The Scanning library is not initialized
SR_INVALID_SCANNER_HANDLE Scanner handle is not valid
SR_SCANNER_NOT_OPEN Scanner is not open
April 8, 2010 Page 52 Document#: 6410-00147 K Revision 2.28
Page 53
8.27 SCANOPENSCANNERPROPERTY
Prototype:
SCANAPI_API SCAN_RESULT ScanOpenScannerProperty(SCANNER_TYPE ScannerType,HANDLE* phProperty);
Purpose:
This API opens access to the properties of a scanner. Most of the time the properties of a scanner is stored in the registry. This API is the preferred way to access to the properties of a scanner instead of accessing directly the registry. While the access to the properties of a scanner type is opened other processes trying to open the access to the properties of the same scanner type will fail. If the call to this API is successful, it returns an handle that can be used in order to read a property value or to write a property value. This handle will need to be freed by using the ScanCloseScannerProperty API.
Arguments:
[in] ScannerType: contains the scanner type the properties belong to. [out]*phProperty: contains the handle to the properties.
Notes:
This API accepts only SCANNER_CHS or SCANNER_CRS as ScannerType.
Returns:
SR_SUCCESS in case of success. SR_INVALID_PARAMETERS if phProperty is NULL. SR_MEMORY_FAILURE if a memory allocation cannot be made. SR_OPEN_FAILURE if property mutex cannot be opened or if the mutex is already taken by another process using this API or if the registry key containing the scanner properties cannot be opened.
8.28 SCANCLOSESCANNERPROPERTY
Prototype:
SCANAPI_API SCAN_RESULT ScanCloseScannerProperty(HANDLE hProperty);
Purpose:
This API closes the access to the properties identified by the handle.
Arguments:
[in] hProperty: handle to the properties that needs to be closed.
Returns:
SR_SUCCESS if the properties handle has been correctly closed. SR_INVALID_PARAMETERS if the handle is not a properties handle.
8.29 SCANGETSCANNERPROPERTY
Prototype:
SCANAPI_API SCAN_RESULT ScanGetScannerProperty(HANDLE hProperty,DWORD dwPropertyID,LPVOID lpValue,DWORD* pdwValueSize);
April 8, 2010 Page 53 Document#: 6410-00147 K Revision 2.28
Page 54
Purpose:
This API can be used to retrieve a value of a property identified by its property identifier. The value type retrieved depends on the property.
Arguments:
[in]hProperty is the handle to access to the properties [in]dwPropertyID is the property identifier the value needs to be retrieved. [out]lpValue is a valid pointer to the property value to retrieve. [in/out]pdwValueSize contains the size of available memory pointed by the lpValue pointer before calling this API, and contains the final size of the values pointed by lpValue after returning from this API call.
Returns:
SR_SUCCESS when the property value has been successfully retrieved. SR_INVALID_PARAMETERS if the hProperty is not a valid property handle or if the property is not a property that can be read or if the value size doesn’t match with the property value size or if the property identifier is unknown.
8.30 SCANSETSCANNERPROPERTY
Prototype:
SCANAPI_API SCAN_RESULT ScanSetScannerProperty(HANDLE hProperty,DWORD dwPropertyID,LPVOID lpValue,DWORD dwValueSize,BOOL bUpdateScannerIfPresent);
Purpose:
This API can be used to modified a value of a property identified by its identifier. Not all properties are modifiable.
Arguments:
[in] hProperty: handle to access the properties to modify. [in] dwPropertyID: identifier of the property to modify. [in] lpValue: pointer to the new value of the property. [in] dwValueSize: size of the new value of the property. [in] bUpdateScannerIfPresent: indicator to update the scanner with the new property value if the scanner is effectively connected or plugged in to the host computer.
Returns:
SR_SUCCESS if the property has been correctly modified. SR_INVALID_PARAMETERS if the property handle is invalid or the property cannot be written or if the value size doesn’t match with the property value size or if the property identifier is unknown.
8.31 PROPERTY IDENTIFIERS
Here is the list of the properties that can be read or written with their value type.
SCAN_PROP_ID_PRODUCT_VERSION
Purpose: Contains the product version. Value type: DWORD. Operation available: Read Only.
April 8, 2010 Page 54 Document#: 6410-00147 K Revision 2.28
Page 55
SCAN_PROP_ID_RING_UNIT_BUILD_ID
Purpose: Contains the ring unit build version. Value type: DWORD. Operation available: Read Only.
SCAN_PROP_ID_PERMANENT_PAIR
Purpose: Flag to activate the permanent pair. Value type: DWORD. Operation available: Read Write and Updateable.
SCAN_PROP_ID_BATTERY_LEVEL
Purpose: Contains the battery level. Value type: DWORD. Operation available: Read Only.
SCAN_PROP_ID_ENABLE_CORDLESS
Purpose: Flag to activate or desactivate the cordless scanner support. Value type: DWORD. Operation available: Read Write.
SCAN_PROP_ID_LOCKOUT_TIMER
Purpose: Trigger lockout timer. Value type: DWORD. Operation available: Read Write and updateable.
SCAN_PROP_ID_ADVANCED_BEEP_FREQ
Purpose: defines the advanced beep frequency. Value type: DWORD. Operation available: Read Write and updateable.
SCAN_PROP_ID_ADVANCED_FLASH
Purpose: flag to activate or desactivate the advanced flash. Value type: DWORD. Operation available: Read Write and Updateable.
SCAN_PROP_ID_ADVANCED_BEEP
Purpose: flag to activate or desactivate the advanced beep. Value type: DWORD. Operation available: Read Write and Updateable.
SCAN_PROP_ID_BEEPER_FREQ
Purpose: define the frequency for the good read beep. Value type: DWORD. Operation available: Read Write and Updateable.
April 8, 2010 Page 55 Document#: 6410-00147 K Revision 2.28
Page 56
SCAN_PROP_ID_TRIGGER_BUTTON
Purpose: contains which scanner buttons triggers the scan. Value type: DWORD. Operation available: Read Write and Updateable.
SCAN_PROP_ID_PRODUCT_TYPE
Purpose: contains the product type. Value type: DWORD. Operation available: Read Only.
SCAN_PROP_ID_WRIST_UNIT_BUILD_ID
Purpose: contains the wrist unit build version. Value type: DWORD. Operation available: Read Only.
SCAN_PROP_ID_MODULE_VERSION_TIME
Purpose: contains the module version time. Value type: DWORD. Operation available: Read Only.
SCAN_PROP_ID_MODULE_VERSION_DATE
Purpose: contains the module version date (month and day). Value type: DWORD. Operation available: Read Only.
SCAN_PROP_ID_MODULE_VERSION_YEAR
Purpose: contains the module version year. Value type: DWORD. Operation available: Read Only.
SCAN_PROP_ID_POWER_SAVE
Purpose: Flag to activate or desactivate the Power save mode. Value type: DWORD. Operation available: Read Write and Updateable.
SCAN_PROP_ID_TRIGGER_MODE
Purpose: flag to activate or desactivate the remote trigger mode. Value type: DWORD. Operation available: Read Write and Updateable.
SCAN_PROP_ID_FLASH_ENABLE
Purpose: Flag to activate or desactivate the LED flashing. Value type: DWORD. Operation available: Read Write and Updateable.
April 8, 2010 Page 56 Document#: 6410-00147 K Revision 2.28
Page 57
SCAN_PROP_ID_BEEP_ENABLE
Purpose: Flag to activate or desactivate the good read beep. Value type: DWORD. Operation available: Read Write and Updateable.
SCAN_PROP_ID_SUPPORTED_CONFIG
Purpose: Bits field indicating what advanced features the scanner supports. Value type: DWORD. Operation available: Read Only.
April 8, 2010 Page 57 Document#: 6410-00147 K Revision 2.28
Page 58
8.32 SAMPLE SYMBOLOGY CONFIG CODE:
8.32.1 Sample Code to Enable or Disable CODE39 symbology:
result = ScanEnableDisableSymbology (hScanner, SYMB_CODE39, TRUE); // Enable
OR
result = ScanEnableDisableSymbology (hScanner, SYMB_CODE39, FALSE); // Disable
if (result != SR_SUCCESS) return FALSE;
return TRUE
8.32.2 Sample code for Read configuration:
if (SYMBOL_RANGE_FLAG[SYMB_CODE39]) { flagsRange.dwStructSize = sizeof( ScannerSymFlagsRange_t ); flagsRange.dwMask = SYM_MASK_ALL; pvSymVoid = (PVOID) &flagsRange; } else { flagsOnly.dwStructSize = sizeof( ScannerSymFlagsOnly_t ); flagsOnly.dwMask = SYM_MASK_ALL; pvSymVoid = (PVOID) &flagsOnly; } result = ScanReadSymbologyConfig (hScanner, SETUP_TYPE_CURRENT, SYMB_CODE39, pvSymVoid);
if (result == SR_SUCCESS) { if (SYMBOL_RANGE_FLAG[SYMB_CODE39]) Flags = flagsRange.dwFlags; else Flags = flagsOnly.dwFlags;
mask = SYMBOLOGY_ENABLE;
if (Flags & mask) { BARCODES_ENABLED[EnabledBarcodes] = (BYTE) SYMB_CODE39; ++ EnabledBarcodes; }
}
Look ahead table for checking if the symbology has a range configuration or not:
BYTE SYMBOL_RANGE_FLAG[SYMB_ALL_SYMBOLOGIES] = { TRUE, // Code 11
April 8, 2010 Page 58 Document#: 6410-00147 K Revision 2.28
Page 59
TRUE, // Code 128 TRUE, // Code 39 TRUE, // Code 49 TRUE, // CODE 93 FALSE, // Code 39 FULL ASCII FALSE, // Tropotic Code39 FALSE, // UPC - A FALSE, // UPC - E FALSE, // UPC - E0 FALSE, // UPC - E1 FALSE, // EAN - 8 FALSE, // EAN - 13 FALSE, // BOOKLAND EAN TRUE, // Composite CODE or UCC/EAN TRUE, // CODABAR TRUE, // CODABLOCK TRUE, // DISCRETE 2/5 TRUE, // IATA 2/5 TRUE, // Interleaved 2/5 FALSE, // ISBT TRUE, // Matrix 2/5 TRUE, // MSI PLESSEY TRUE, // RSS 14 FALSE, // TLCODE 39 FALSE, // Australian Postal TRUE, // AZTEC FALSE, // AZTEC MESA FALSE, // British Postal FALSE, // Canadian Postal TRUE, // Data Matrix Code FALSE, // Dutch Postal FALSE, // Japanese Postal TRUE, // MaxiCode TRUE, // Micro PDF TRUE, // OCR TRUE, // PDF TRUE, // QR CODE FALSE, // US Planet Postal FALSE, // US Postnet Postal };
Structures ScannerSymFlagsRange_t & ScannerSymFlagsOnly_t are declared in ScanAPI.h file for your reference.
8.32.3 Sample Code to Enable or Disable CODE39 symbology:
result = ScanEnableDisableSymbology (hScanner, SYMB_CODE39, TRUE); // Enable
OR
result = ScanEnableDisableSymbology (hScanner, SYMB_CODE39, FALSE); // Disable
if (result != SR_SUCCESS) return FALSE;
return TRUE
April 8, 2010 Page 59 Document#: 6410-00147 K Revision 2.28
Page 60
9.0 CORDLESS SCANNER (CS) SPECIFICS
The Cordless Scanners integrate Socket barcode scanning capabilities into a cordless solution. The user can now program the same functionality provided in our SDK through a Bluetooth connection. Along with these changes new APIs are required to configure and manage the Bluetooth connection as well as the scanner.
To provide CS functionality is straight-forward. A simple call to ScanEnableCHS() to load the driver and the creation of a user defined message type to handle the connection status is all that is needed! The following information on the relevant APIs and registry settings should provide the required details. An example of its usage is also available in the sample code.
The CHS and CRS require that Connect!Agent be installed upon the target device. Connect!Agent simplifies the process of discovering and connecting to CHS and CRS devices and allows ScanAPI to work with a variety of different Bluetooth stacks.
Another feature of the Cordless Scanners is remote vs. local scanning options. When remote scanning is selected all communication with the PDA is confirmed, hence you cannot trigger a scan until the PDA acknowledges the scan request. Local scanning is a faster and more efficient scanning method; it does not require all communication to be confirmed. Remote works best when the connection proves to be unreliable or when distances are greater; whereas, local scanning is intended for short range scanning.
The CS MUST always receive a response from the application for the trigger button to be responsive. If no response is sent back, the trigger button will resume operation after a 10 second lockout. In the case where a user wishes to send a negative ACK back to the CS they can call ScanSendCmdtoCHS () with payload of 0x06 (SET_INDICATORS_CMD) and command of 0x00 (None), which will result in no beep or sound being generated.
For this mode of operation the following key must be added to the registry:
HKLM,"Software\Socket Communications\CHS\1.0", " AutoSendGoodScanInd",0x00010001, 0x00
For more information, refer to registry setting details later in this chapter.
© Socket Communications, Inc. November 16, 2004 Revision 2.18
Page 61
9.1 SCANENABLECHS()
Prototype:
SCANAPI_API SCAN_RESULT ScanEnableCHS(HWND hWnd, UINT wmCHSStatus);
Purpose:
This function activates the Cordless Scanner and loads its driver.
Arguments: [in] hWnd is the handle of the CS status window – receives CS notification messages
[in] wmCHSStatus is the user status of the CS – it notifies the state of dynamic reconnection, if the connection is lost, or reconnected. Generally this is a user defined message handle.
Notes: This function is only relevant to CS. This function will send a wmInsertion message to the main window.
Returns:
SR_SUCCESS The operation completed successfully.
SR_INVALID_WMCHSSTATUS The wmCHSStatus message is not within the allowed User message range.
SR_NOT_INITIALIZED The scanner has not been initialized
SR_INTERNAL_FAILURE The CHS driver failed to load.
April 8, 2010 Page 61 Document#: 6410-00147 K Revision 2.28
Page 62
9.2 SCANDISABLECHS()
Prototype:
Windows CE:
SCANAPI_API SCAN_RESULT ScanDisableCHS(HANDLE hScanner);
Windows XP:
SCANAPI_API SCAN_RESULT ScanDisableCHS(HWND hWnd, HANDLE hScanner);
Purpose:
This function will disable CHS and unload the CHS driver
Arguments:
[in] hScanner is the scanner id used to disable the CHS
Notes:
This function is only relevant to the CHS. This function will send a wmRemoval message to the main window.
Returns:
SR_SUCCESS The operation completed successfully.
SR_DEVICE_FAILURE Unable to communicate with the scanner
SR_INTERNAL_FAILURE The CHS driver failed to load.
April 8, 2010 Page 62 Document#: 6410-00147 K Revision 2.28
Page 63
9.3 SCANSENDCMDTOCHS()
Prototype:
SCANAPI_API SCAN_RESULT ScanSendCmdtoCHS(HANDLE hScanner, PBYTE paramIn, UINT paramInLen, DWORD Timeout)
Purpose:
Send Configuration commands to CHS – Battery status inquiry, Self test inquiry (CHS version information), Friendly Name inquiry, Set Friendly Name, Set Security (PIN, Authentication), Delete Pairing & Bonding and Set Device configuration. Refer to later sections for more details on command options.
Arguments:
[in] hScanner is the value received by the client application in lParam of the WM_INSERTION message specified when ScanInit() was called.
[in] paramIn is a 8 bit buffer containing the parameter number that will be retrieved. In this buffer the first byte contains the CHS configuration command opcode. The following byte(s) contain the parameter value. The SCANAPI opcodes for CHS commands are:
#define SET_SECURITY_MODE_CMD 0 #define SET_FRIENDLY_NAME_CMD 1 #define SET_PIN_CODE_CMD 4 #define SET_DEVICE_CONFIG_CMD 5 #define SET_INDICATORS_CMD 6 #define BATT_CHRG_STATE_INQ_CMD 8 #define FRIENDLY_NAME_INQ_CMD 10 #define DEL_PAIRING_BONDING_CMD 11
For Example to issue a Set Security mode command check the following sample code:
paramIn[0] = SET_SECURITY_MODE_CMD; paramIn[1] = 0 or 1 or 2; paramInLen = 2; Timeout = 3;
ScanSendCmdtoCHS (hScanner, paramIn, paramInLen, Timeout);
[in] paramInLen is the length of the paramIn buffer in bytes
[in] Timeout is the timeout for CHS configuration command response, specified in seconds
Returns:
Upon exit, this will be set to 0 if an error occurs, non-zero value otherwise.
SR_SUCCESS The operation completed successfully.
April 8, 2010 Page 63 Document#: 6410-00147 K Revision 2.28
Page 64
SR_NOT_INITIALIZED Library is not initialized
SR_INVALID_SCANNER_HANDLE Invalid Scanner handle
SR_DEVICE_FAILURE IO Control call FAILS
SR_WAIT_TIMEOUT_ERROR CHS configuration response timeout has occurred
April 8, 2010 Page 64 Document#: 6410-00147 K Revision 2.28
Page 65
9.4 BLUETOOTH CONNECTION STATUS
When the CHS is configured, the Bluetooth stack needs to be enabled. Along with the appropriate registry settings – refer to the section on registry configuration, the wParam and lParam values are used to communicate the state of the stack.
To enable the CHS the “ScanEnableCHS(HWND hWnd, UINT wmCHSStatus)” function is called. The second parameter is a user defined message that can be customized to handle the three possible CHS Bluetooth states.
The wParam range for a wmCHSStatus message is:
CHS_BTLINK_DROPPED CHS_BTLINK_ABORTED CHS_BTLINK_RE_ESTABLISHED CHS_RING_DISCONNECTED
Refer to the SDK sample code for an example. Depending on the desired action, the user should customize the error status for their particular application.
April 8, 2010 Page 65 Document#: 6410-00147 K Revision 2.28
Page 66
9.5 CHS COMMANDS
These tables show the various codes that can be sent to configure the CHS via the SendCmdToCHS() API.
9.5.1 Set Security Mode
Set Security Mode
Field Name Format Size Description
Opcode 0x00 1 Byte Set Security mode
Payload
9.5.2 Set Friendly Name
Set Friendly Name
1 Byte Select
Bluetooth security mode
0x00 = None
0x01 = Authentication
0x02 = Authentication +Encryption
Field Name Format Size Description
Opcode 0x01 1 Byte Opcode for setting friendly
Payload
9.5.3 Set PIN Code
Set PIN Code
Field Name Format Size Description
Opcode 0x04 1 Byte Set Pin Code
Payload
name
None Update registry entry
“Friendly Name” with
1 to 248 character string before issuing this command
None Update registry entry “PinCode”
with 1 to 16 byte string before issuing this command
April 8, 2010 Page 66 Document#: 6410-00147 K Revision 2.28
Page 67
9.6 CHS CONTROL COMMANDS
9.6.1 Set Indicators
Set Indicators
Field Name Format Size Description
Opcode 0x06 1 Byte Light LED and or Beep
Payload
9.6.2 Battery Charge State Inquiry
Battery Charge State Inquiry
Field Name Format Size Description
Opcode 0x08 1 Byte Request battery status
Payload
1 Byte Select
None
indicator to activate: 0x00 = None
0x01 = Beep
0x02 = Flash Green LED
0x03 = Beep and Flash Green LED
9.6.3 Battery Charge State Response
Battery Charge State Response
Field Name Format Size Description
Response 0x00 to 0x64 1 Byte Battery charge state 0-
9.6.4 Friendly Name Inquiry
Friendly Name Inquiry
Field Name Format Size Description
Opcode 0x0A 1 Byte Request Friendly Name
Payload
None
100 % is updated in registry entry “BattCharge”
April 8, 2010 Page 67 Document#: 6410-00147 K Revision 2.28
Page 68
9.6.5 Friendly Name Response
Friendly Name Response
Field Name Format Size Description
Response
Variable 1 to 248 character string
is updated in registry entry “FriendlyName”
April 8, 2010 Page 68 Document#: 6410-00147 K Revision 2.28
Page 69
9.7 REGISTRY SETTINGS FOR THE CORDLESS HAND SCANNER
Compared to previous versions of SocketScan, this version relies on Connect!Agent exclusively to simplify the process of configuring and establishing a Bluetooth connection to a cordless scanner. Refer to the Connect!Agent documentation in this SDK for more information.
HKLM,"Software\Socket Communications\CHS\1.0", " BattCharge",0x00010001, 0x64
This key is used to check the Battery charge level in the CHS
HKLM,"Software\Socket Communications\CHS\1.0", " BeeperFreq”, 0x00010001, 0x01
This key is used to set the CHS beeper frequency
HKLM,"Software\Socket Communications\CHS\1.0", "Beep",0x00010001, 0x01
Should the CHS beep on a good read?
• No 0
• Yes 1
HKLM,"Software\Socket Communications\CHS\1.0", " CHSPICVer", 0x00010001, 0x01
This key defines the PIC version, in the CHS
HKLM,"Software\Socket Communications\CHS\1.0", " CHSVerMonthDay", 0x00010001, 0x1015
This key defines the build version, month & day in the CHS
HKLM,"Software\Socket Communications\CHS\1.0", " CHSVerTime", 0x00010001, 0x0923
This key defines the build version, time in the CHS
HKLM,"Software\Socket Communications\CHS\1.0", " CHSVerYear", 0x00010001, 0x2004
This key defines the build version, year in the CHS
HKLM,"Software\Socket Communications\CHS\1.0", "Flash", 0x00010001, 1
Should the CHS flash green LED on a good read?
• No 0
• Yes 1
HKLM,"Software\Socket Communications\CHS\1.0", " FriendlyName ", 0x00000000, CHS Scanner
This key defines the friendly name of the CHS
HKLM,"Software\Socket Communications\CHS\1.0", " PinCode ", 0x00000000, 31 32 33 34
This key defines the Pin code to be set in the CHS
HKLM,"Software\Socket Communications\CHS\1.0",” PowerSave ", 0x00010001, 0x00
April 8, 2010 Page 69 Document#: 6410-00147 K Revision 2.28
Page 70
This key defines the Auto-power off feature in the CHS
HKLM,"Software\Socket Communications\CHS\1.0", "TriggerMode",0x00010001, 0x00
This key sets the trigger mode. Local scanning is for short distances to the PDA; whereas, remote scanning when the PDA connection is further or more unreliable.
• Local (Scan always) 0
• Remote triggering (Only when connected to host) 1
HKLM,"Software\Socket Communications\CHS\1.0",” UseCHS",0x00010001, 0x00
This key defines whether the user has enabled CHS support in the Scanner Settings control panel applet. SocketScan.exe uses this registry entry to determine whether to display CHS/CRS specific UI elements.
HKLM,"Software\Socket Communications\CHS\1.0",” AutoSendGoodScanInd", 0x00010001, 0x01
This key defines if the CHS driver will automatically send a “good scan” indication (beep and/or flash) to the CHS after receiving a scanned bar code.
If the registry entry is set to 0, then a good scan acknowledgement must be sent by the application (by sending a ‘Set Indicators’ command.) Every time the CHS reads a barcode, it expects a good scan acknowledgement (‘Set Indicators’ command). If it does not receive it, it waits for 10 seconds to receive it during which it disables scanning capability. Scanning is enabled automatically after the 10 second timeout. Please refer to Chapter 9.5/9.6 for more details about issuing Set Indicator commands.
If the ‘AutoSendGoodScanInd’ registry entry is set to 1, then the driver automatically sends a ‘Set Indicators’ command after every scan. The parameters for the ‘Set Indicators’ command are determined by the value set for ‘Beep’ and ‘Flash’ registry entries.
NOTE: If the registry entry is changed after a CHS connection has been established, the connection should be disconnected and reconnected for the change to take effect.
April 8, 2010 Page 70 Document#: 6410-00147 K Revision 2.28
Page 71
10.0 RFID READER
The Socket CF RFID Reader Card allows the reading and writing of numerous HF RFID tags. The SDK gives the programmer full control over the RFID Reader and tag functions. The CF RFID Reader Card can also respond to standard ScanAPI functions for triggering and retrieving scanned data. The data that is returned can be a combination of the tag ID and data stored on the card and is configurable through registry entries and/or the Scanner Settings control panel applet.
Refer to the Socket RFID SDK User’s Guide for more information about the RFID functions and operation.
April 8, 2010 Page 71 Document#: 6410-00147 K Revision 2.28
Page 72
11.0 MULTISCANNER SUPPORT (WIN CE ONLY)
The following describes the changes to SocketScan to handle the CF RFID Reader-Scan Card. The CF RFID Reader-Scan Card is really two scanners in one: RFID + CFSC. This version treats the CF RFID Reader-Scan Card as two individual scanning devices and therefore extends beyond just the CF RFID Reader-Scan Card to allow other scanners to coexist. One example is the CF Scan Card (CFSC) and the Cordless Hand Scanner (CHS).
NOTE: Currently, the SDK doesn’t support two hardware configurations: CFSC or CF RFID Reader-
Scan Card and the SD Scan Card.
This version of the SDK allows for multiple scanners if enabled. The goal was to maintain backward compatibility so ScanAPI works exactly like it has with legacy applications (non-multiple-scanner aware). A new scanner API call was added that tells ScanAPI that the application supports multiple scanners. The change to an application to support multiple scanners is the ability to handle multiple wmInsertion and wmRemoval callback messages. When the CF RFID Reader-Scan Card is inserted and an application is registered with ScanApi.dll, it will receive two wmInsertion callbacks (one for RFID and one for CFSC). Each wmInsertion callback will include a unique scanner handle that is used to communicate with that particular scanning device. The scanner handle is used to trigger the device, get scanner status, and determine when data is available from the scanner. In the past this scanner handle has always been assumed to be 1 and still is when the multiple scanning capability is not enabled. It can now range from 1 to 10.
This version of Scan API also supports scanner triggering using a new SendMessage command. The application or a stand-alone program can send a message to ScanAPI to trigger a particular scanner independent of which application is running. (The previous version only allowed an external trigger through the SocketScan.exe application.) To help this process some of the scanner handles have been reserved based on the scanner type. This provides a consistent way to trigger a particular scanning device independent of the "insertion order." The predefined scanner handles are:
RFID ISC/RFID-ISC SDSC CHS/CRS CF Scan Card 5X MAGSTRIPE
1 2 3 4 5 6
Note: The predefined values are defined in the Plug-n-Play string for the scanner type (see DesiredHandle for more information).
In the case of multiple scanners with predefined handles, the first scanner gets the reserved handle number and all other scanners of that type get the first available scanner handle starting with 10 and working downwards.
A few sample programs have been precompiled to trigger the RFID and CFSC scanners, namely TriggerRFID.exe and TriggerISC.exe. Assigning these programs to a button on the PDA will trigger the RFID or CFSC scanner (if the scanner is present). The developer can use these applications or compile his own to take advantage of this feature.
11.1 REGISTRY SETTINGS FOR THE CF RFID READER-SCAN CARD
DisablePlugSnd
April 8, 2010 Page 72 Document#: 6410-00147 K Revision 2.28
Page 73
Set to 1 to disable the insertion sound. If the entry is missing or set to 0, SocketScan will beep when an insertion message is received for this device. (Used to keep SocketScan from beeping twice when the RFID-Scan card is inserted).
[HKEY_LOCAL_MACHINE\Drivers\PCMCIA\<YOUR PNP ID>\Scanner 2] "DisablePlugSnd"=dword:00000001
DesiredHandle To implement the handle numbers, just add the "DesiredHandle" DWORD value to the registry for each scanner – for instance (range 1 to 10):
[HKEY_LOCAL_MACHINE\Drivers\PCMCIA\<YOUR PNP ID>\Scanner] "DesiredHandle"=dword:00000001
[HKEY_LOCAL_MACHINE\Drivers\PCMCIA\<YOUR PNP ID>\Scanner 2] "DesiredHandle"=dword:00000002
April 8, 2010 Page 73 Document#: 6410-00147 K Revision 2.28
Page 74
12.0 USING SOCKETSCAN (KEYBOARD WEDGE)
If your scanning application is very simple, or your development language is not able to call a DLL, you may find that using the SocketScan keyboard wedge software (ScktScan.exe) will fill your needs. SocketScan simply runs in the background monitoring scanning devices and, when data is scanned, it is sent to the application that currently has the keyboard focus. You may define a prefix and suffix that will be added to the scanned data, if desired.
There are several drawbacks to this approach. Probably the biggest drawback is that you have no control over where the data is going – you must take it on faith that the user has selected the appropriate control to receive the scanned data.
Additional features of SocketScan can now be utilized by the creation of a special DLL. By creating a SocketScan “Preview DLL”, you can process the scanned data before the data is submitted to the keyboard. This gives you the flexibility, for example, to change the data prefix or suffix on-the-fly, shave or filter unwanted characters from the scanned data, etc.
The obvious benefit of using SocketScan is that it works with ANY application that is designed to accept keyboard input (which is most applications). Data can be scanned into Word Mobile or Excel Mobile as easily as it can be scanned into your application. No changes are required to your existing application code whatsoever.
SocketScan can be downloaded for your target platform from
http://www.socketmobile.com/support/downloads/data-collection/
April 8, 2010 Page 74 Document#: 6410-00147 K Revision 2.28
Page 75
13.0 SOCKETSCAN TRIGGER APPLICATIONS (WINCE ONLY)
SocketScan now supports multiple scanners as well as a number of scan trigger options. This is a short description of those scan trigger options.
The following programs can be used to trigger a scanning device:
SocketScan Trigger Select Trigger Scan Trigger RFID Trigger “xyz”
SocketScan is a keyboard wedge application as well as a trigger program. If the program is assigned to a
PDA button and pressed, it will either load SocketScan, and install itself as a keyboard wedge, or act as a scan trigger application. It does this by first detecting if it’s already running or if RFID Demo or ScanDemo are running. If it finds one of these three programs running, it sends a message to the running application to tell it that a scan trigger is needed. In the case of SocketScan or ScanDemo, this triggers the “selected” scan device (the one shown with the checkmark in the application’s menu). For RFID Demo, it always triggers the RFID scanner.
Trigger Select works specifically with SocketScan and is not really a trigger program but used to advance SocketScan to the next “selected” device. It switches only to scan devices that only have software triggers (this includes RFID, CFSC, and SDSC – it does not include the CHS or CRS). This program is used in conjunction with SocketScan to do the actual triggering.
Trigger Scan and Trigger RFID make calls directly to ScanAPI to do a ScanTrigger. These calls are independent of the running application so they will work with the existing SocketScan applications as well as user-written applications. These trigger programs call ScanAPI will a Scanner Handle that’s associated with the scanner type.
Note: The predefined scanner handles are only valid when ScanApi.dll has been enabled for Multiple Scanners. ScanApi defaults to single scanner mode and the scanner handle is always 1. Since Trigger RFID uses scanner handle 1, it would then trigger whatever scanner was active in the device (provided it accepted a software trigger).
Trigger “xyz” is listed here because it is a user-defined trigger program. Source code for this program is provided in the SDK and all the programmer needs to do is modify the code with the desired scanner handle and compile the program to create a new trigger application. Trigger Scan and Trigger RFID were created in this way. See the SDK documentation for a list of predefined scanner handle numbers.
Using the above applications to trigger the RFID scanner may not be the best solution. The ScanTrigger function in ScanApi.dll supports RFID scanning in “legacy” mode. Originally it would only scan the tag IDs (calling Select Tag in the RFID driver). This was done to mimic the reading of a bar code. This version of SocketScan allows that to be expanded depending upon registry settings controlled by the RFID Setup control panel applet. After installation it defaults to reading only the tag IDs but can be changed to read the tag data blocks or both the tag IDs and data blocks. This may be useful if the user wants a simple way to import tag data into a spreadsheet but if more control is needed, a user application needs to be written using the RFID SDK.
The following is a table shows the trigger applications and compatibility with both the supplied SocketScan applications and the user-generated application.
Trigger Applications Assigned to Buttons
April 8, 2010 Page 75 Document#: 6410-00147 K Revision 2.28
Page 76
SocketScan.exe RFIDDemo.exe ScanDemo.exe User application (using SDK)
SocketScan Trigger Select Trigger Scan Trigger RFID
Yes Yes Yes Yes Yes* No No Yes* Yes No Yes Yes
No No Yes Yes
* Note: Socket does not recommend using SocketScan or Trigger RFID to do a tag read while using RFID Demo. The data may not appear as expected due to the different options that can be enabled in the Scanner Settings control panel applet.
RFID Demo only utilizes the RFID portion of the CF RFID Reader-Scan Card.
Whenever these programs are assigned to buttons to trigger a RFID scan, they call ScanTrigger API routine which generates a Select Tag and/or Tag Read Data command. The parameters for this command are set by the registry entries and controlled by the Scanner Settings control panel applet.
13.1 TRIGGERING DETAILS
If you are using SocketScan with the CF Scan Card or SD Scan Card for your application, there are two ways to start a scan:
1. Assign a hardware button to execute the Socket Trigger Scan.exe, Socket Trigger RFID.exe or
ScktScan.exe program. If ScktScan.exe is already loaded, executing it again will call ScanTrigger() to start a scan.
2. Your application program can execute ScktScan.exe to start a scan.
For the RFID Reader, assigning a trigger button or executing ScktScan.exe to start a trigger sends a Select Tag command to the RFID reader. If a valid tag is within the reader’s field, SocketScan returns the Tag Type and Tag ID (with a “:” in-between) to the current application that has keyboard focus. Use the SocketScan RFID control panel applet to configure SocketScan to read the tag data and for better control over the RFID Reader functions when triggered from ScanAPI.
SocketScan (keyboard wedge) now has the addition of the "selected" scanner. This is the scanner who's ICON shows up in the task tray and has a checkbox (selected) when the SocketScan menu is displayed. The selected scanner is the one that receives the ScanTrigger command when SocketScan is assigned to a PDA button and executed.
A number of changes were made to the SocketScan wedge program to support the RFID-Scan card and multiple scanners in general.
1. The program is now multi-scanner aware by calling ScanEnableMultiScanner() before calling
ScanInit(). It does not support multiple CHS devices at this time.
2. The CF RFID Reader-Scan Card is treated as two scanning devices: RFID and CFSC. The program
also supports other scanner combinations (i.e. CHS and CFSC, CHS and RFID, etc.)
3. Symbology Selector:
When multiple bar code scanners are present (i.e. CFSC and CHS) the symbology selector will show a sub-menu for all scanners that support displaying/changing the symbologies. There is no sub-menu if there is only one supported scanner present
April 8, 2010 Page 76 Document#: 6410-00147 K Revision 2.28
Page 77
13.2 CHANGING THE ACTIVE SCANNER
Support for a windows message that changes the active been implemented. This message allows the caller to set the active SocketScan scanner in one of three ways.
The format is:
Select the next scanner (wraps around after the last scanner). This only selects scanners with software-only triggers: SendMessage(socketScanWnd, WM_SELECT_SCANNER, 0, 0);
Select the specified scanner handle: SendMessage(socketScanWnd, WM_SELECT_SCANNER, 2, 0);
Select the first scanner of the specified scanner type: SendMessage(socketScanWnd, WM_SELECT_SCANNER, 0, SCANNER_CHS);
1) If scanner and scannerType are both zero, select the next scanner
2) If scanner is non-zero, select the scanner with that handle
3) If scannerType is not SCANNER_NONE (0), select the first scanner of that type
SelectNext.exe has been precompiled and included in the SocketScan build. You can assign SocketScan.exe to one PDA button and SelectNext.exe to a second PDA button. This allows you to trigger the "selected" scanner and advance to the next scanner. In case of the RFID-Scan card the SelectNext button will toggle between RFID and CFSC scanners.
If the CHS is also enabled it will not be included in the toggle since it has a hardware trigger. (The CHS can be made the "selected" device using the SocketScan menu and then the PDA button would remotely trigger the CHS.)
scanner (WM_SELECT_SCANNER) has
April 8, 2010 Page 77 Document#: 6410-00147 K Revision 2.28
Page 78
14.0 THE DRIVERMAN DLL
DriverMan is a Windows CE device driver created by Socket to provide services and functionality for managing one or more drivers associated with an expansion card. DriverMan exists as a dynamically loaded library (DLL) named DriverMan.dll. DriverMan expands upon and improves the device driver model provided by the Windows CE OS. It supports more loading and unloading options as well as providing more debugging and error-handling capabilities than the built-in device.exe process.
One of the key benefits of DriverMan is that it loads and unloads drivers in a specified, synchronous order, and it also enables confirmation of initialization for sequencing the loading of drivers that need additional time to initialize using multiple threads. Overall it allows the SocketScan initialization/de-initialization to be far more robust in providing controlled startup and shutdown. DriverMan is required for all Windows CE scanner drivers and is included in the Drivers directory of the SDK.
April 8, 2010 Page 78 Document#: 6410-00147 K Revision 2.28
Page 79
14.1 IMPLEMENTING A SOCKETSCAN PREVIEW DLL
A SocketScan Preview DLL can be as simple or as complex as you want to make it. There are very few requirements to follow:
• The DLL must export a function called DataPreview.
• The basic prototype for the function is: int DataPreview(TCHAR * lpData, int nSize). See the
sample DLL files on the CD for the exact declarations for Win CE and Win XP, located in the \Source\Preview DLL directory.
• You may modify the characters in lpData and change the number of characters, but the
maximum buffer size is 1500 characters (plus room for a NULL).
• The DataPreview function must return the number of valid characters in the buffer.
• You must add a registry entry to tell SocketScan that this DLL exists. Under the registry key
HKEY_LOCAL_MACHINE\Software\Socket Communications\ScktScan\1.0, create a string value called PreviewDll, and set its value to the path and filename of the DLL you’ve created.
Very simple examples of a Preview DLL are on the distribution CD in the \Source\Preview Dll directory, one for Windows CE, one for Windows XP. These examples simply delete the first character from the scanned data.
Here are a few things to keep in mind when designing your Preview DLL:
• When creating the Preview DLL with C++, don’t let the exported DataPreview() function
name get mangled.
• When expanding the size of the scanned data, be careful not to exceed the 1500 character
limit. Doing so will most likely cause Access Violation errors in the SocketScan program. Likewise, do not attempt to free the memory pointer given in the lpData argument.
• To “throw out” the scanned data, there is no need to zero out the data buffer – instead
simply use zero as your function return value.
• SocketScan will not add a prefix or suffix to the data when a Preview DLL is being used, even
if prefix and suffix strings have been configured in the program. Add your own prefix or suffix in the DataPreview() function if desired.
• Your DataPreview() function should simply do its operation on the data, then move on as
quickly as possible. Do not pop up message boxes or other UI elements in this function, since the user may continue to scan data instead of respond to your UI – this could lead to re­entrancy or other unexpected problems in your DLL.
• SocketScan does not null-terminate data and typically your DataPreview() function will not
need to do so either. You probably don’t want a NULL keystroke to occur in your data entry fields.
• Remember you are dealing with UNICODE on CE devices, and probably are not on Win32
Desktop OS. Keep in mind that the nSize argument is always the character count regardless of the OS.
Here are a few ideas and reasons for using a Preview DLL:
• Some barcodes (such as Vehicle Identification Numbers) begin with a character that may not
be wanted in the custom application. A Preview DLL can easily knock this character off the data stream.
• You may want to translate characters that the user has scanned to other characters – for
example change dollar signs to British pound signs, etc.
April 8, 2010 Page 79 Document#: 6410-00147 K Revision 2.28
Page 80
• Route a copy of the scanned data to the serial port of the host device or to some other
auxiliary data collection receiver, if desired.
• You may want certain barcodes to spawn some other process on the host computer, or play a
.WAV file, .AVI or .MPG file, etc.
• If you are printing your own barcode labels, you can include characters that have special
meaning to your application trigger special processing based on their presence, and filter them out of the final data stream.
• By adding your own private functions into the Preview DLL, your custom application can tell
the DLL which input field has the focus at any given time. With this information you can validate the scanned data, or even change the suffix from a TAB to a CARRIAGE RETURN when it is appropriate to do so in your application.
We believe the addition of the Preview DLL has made SocketScan a much more powerful tool. We hope that developers will find that SocketScan with this extension can be used as the scanning solution for their application, and reduce the chances that you will need to write code all the way down at the ScanAPI level.
April 8, 2010 Page 80 Document#: 6410-00147 K Revision 2.28
Page 81
15.0 IMPLEMENTING A SOCKETSCAN APPLICATION IN .NET
The ScanAPI .Net Compact Framework and .Net Framework Class libraries provides a simple to use interface to Socket data collection products for applications written in .Net compliant languages such as Visual Basic.Net or C#.Net.
Refer to the ScanAPI .Net User’s Guide in the docs directory section of this SDK for further detail
April 8, 2010 Page 81 Document#: 6410-00147 K Revision 2.28
Page 82
16.0 SYMBOLOGY SUPPORT BY SCANNER TYPE
The following table itemizes the symbologies and the bar code scanners that support them. Bar code symbology support is implemented in the scanner engine firmware. A new firmware version may revise the list of supported symbologies. This list will be revised if the engine firmware is updated on the scanner device.
Scanning Engine Symbol CSE-600 Symbol SE-955 or SE-955EL
Relevant Products SD Scan Card 3E
CF Scan Card 5E
CHS 7E
Matrix Bar codes /2D N/A N/A Aztec, Codablock, Data Matrix, GS1
Postal Codes N/A N/A Australia Post, BP0 4, Canada Post,
Linear Bar codes Code 11, Code 39,
Code 39 Full ASCII, Trioptic Code 39, Code 93, Code 128, UCC EAN 128, Codabar, UPC, Bookland EAN, Interleaved 2 of 5, MSI Plessey, Coupon Code, Discrete 2 of 5
SD Scan Card 3E2, 3M, 3P
CF Scan Card 5E2, 5M, 5P
CHS 7E2, 7M, 7M2, 7P, 7NRx
CRS 9M, 9P
Chinese 2 of 5, Codabar, Code 11, Code 128, Code 39, Code 93, Discrete 2 of 5, GS1 DataBar (RSS), GS1-128 (UCC-128/EAN-
128), Interleaved 2 of 5 (ITF-14), ISBN, MSI, UPC/EAN, Webcode
Intermec EA15
CF Scan Card 5X, 5XRx
CHS 7X, 7XRx
(EAN.UCC), Matrix 2 of 5, Maxicode, PDF 417/ Macro PDF 417/ Micro PDF 417, Plessey, QR Code, RM4SCC, Standard 2 of 5
Dutch Post (KIX), GS1 (EAN.UCC), Japan Post, Planet, Postnet, RM4SCC, Sweden Post, Telepen, TLCode 39, 4 State Code
Codabar (including support for ISBT 128 bit concatenation), Code 11, Code 128, Code 39, Code 93, Discrete 2 of 5, GS1 DataBar (RSS), GS1-128 (UCC-128/EAN-128), Interleaved 2 of 5 (ITF-14), ISBN, MSI, UPC/EAN, Webcode
April 8, 2010 Page 82 Document#: 6410-00147 K Revision 2.28
Loading...
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use