Aaron: after many years of dealing with many different types of barcode
readers, may I share with you some recommendations?
1) If at all possible, use a serial barcode reader. These typically operate
at 9600bps whereas the keyboard usually runs at 300bps. The higher serial
speed will make your application seem more responsive.
2) Create a component subclassed from TEdit or whatever, which looks for
input from your serial port. Since whatever you're using to drive the port
will need to be global (I'm assuming you will have only one reader per
machine), get it to take ownership of the port when it receives focus, and
relinquish ownership when it loses focus.
3) If you can, use hardware handshaking (RTS/CTS) so that if a user scans a
barcode when no barcode field is active, you don't get a "Good Read" beep,
or at least there will only be one beep, then the reader will refuse to
operate until your application has accepted the data. This _does_ help
operators.
4) If you use the scenario in (3), remember to drain the port when you
activate it, so you don't get a an accidental read from 10 minutes ago which
is still waiting in the reader.
5) If you want to auto-activate a barcode field when a read comes in, set a
global variable (hopefully in the code you're using to drive the port)
indicating where the port should set the focus, and have the port point out
that it should _not_ be drained.
6) You can use much the same logic as described above to drive a credit card
reader, though you'll need to have pairs of fields for card number and
expiry dates.
7) When you do create your TBarcodeField component, include a method for the
driver to call telling it to skip to the next field (or whatever, maybe do a
validate on product code, isbn etc )
8) DO NOT use TBarcode fields to allow entry of quantity or price. Although
some barcodes have prices and weights encoded in them, just have the driver
make the information available, and have the other fields check for the
presence of that information. Remember, your TBarcodePortDriver is probably
going to be global.
9) Hardware-wise, lasers are faster and more reliable at reading than leds,
but they are far more prone to failure as a result of poor handling. Check
out the "barcode won't scan so knock the reader on the bench" scenario.
Good for hardware sales. Those old LED wands make great bungy toys for
bored salespeople, but when the ruby reading tip hits the concrete floor, it
is probably history. Presentation scanners (like they use at the
supermarkets) last the longest, but are unsuitable if the operator needs to
scan goods on a trolley: e.g. a tray of steinies.
10) If you're a whizz with serial ports, then I'm sure you can make a
whizz-bang TBarcodePortDriver, but if not, you can still make a pretty good
driver with its parameters being configured with a string like
"com1:9600,n,8,1". Simply yet surprisingly effective.
Hope this helps
Trevor
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
The client has lef the options open with respect to locating a barcode
reader
to use with our application. What are people experiences with various
barcode
readers and delphi connectivity software - can anyone make recommendations
on barcode type (led/laser), connectivity format (serial/keyboard) and
application
API packages.
I understand that some of the keyboard barcode readers can send pre and post
character streams to enable jumping to the barcode field and tabbing to the
next
field automatically - comments?
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
