5.0
W
RITING
Y
OUR
A
PPLICATION
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
