>What do you mean "purchase a barcode reader". It's not any code I can write or something????
No, purchase a barcode
font. The same way that you'd buy a special font needed from Adobe for a page preparation tool, or Word, if the font didn't come with something you already owned. From VFP's perspective, once the font is installed under Windows, you simply set a field's output to use that font, scaled and positioned appropriately for your needs in a report form, or using ?/??, and it's over and done. No special code is needed. No hardware dependency. No sweating 'what does that new printer they installed yesterday do to my application?'
The reason to buy a font rather than rolling your own graphics (which I did in FPDOS) is that it's device-independant. You don't care about if it's an inkjet, an HP LaserJet actalike, a PostScript printer, or a thermal label printer. Win32's GDI worries about the hows and whys and wheres of translating the output to the control sequences needed for the printer, with the appropriate hardware handling.
It's the same reason you don't write your own print port driver. Sure, you could do it (you could create your own font using a font editor, too, if you wanted to) but
it's nearly always cheaper to buy it off the shelf and equally important,
you don't have to deal with the nuances of low-level device handling. You aren't concerned with operating system changes. And things don't suddenly break when the printer is network-attached, or uses a USB port...
In my case at least, it's much more cost effective to buy a $50-100 font that someone else has already put through the paces of ensuring that it works properly and meets the barcode font specs, than it would be for me to spend 2 hours writing graphics code (I wish!) and who knows how many hours testing and debugging. It's the same logic behind buying VFP, or a C compiler - you could probably write something to do the job, but it's cheaper, easier and from an application standpoint, safer, to buy a tool and write a few hundred lines of code do what's than to write a few hundred thousand lines of code to avoid buying a supported product. You could write your own operating system while you're at it, too...
As far as the reader, unless you're a real whiz at laser optics and electronics, buying a reader that someone else built and using the interface that comes with it is probably a better better than trying to design and build your own bar code reader hardware. In my work, I use what's referred to as a wedge - it's a barcode reader that interfaces through the keyboard of a PC - on our shipping stations to read the barcode from pick lists created by our VFP order entry application - from the shipping application's POV, it's just another source of keyboard input, and when I create my picklist report, it's just another output field with a different font selected.
I've also used serial barcode reader devices, and dedicated barcode readers that completely relieved the PC of any responsibility for the scanning process; Pitney Bowes sells a whiz-bang unit that we use in our warehouse to scan the barcodes off cases of books at inventory time; it's a wireless LAN device that outputs a comma-delimited text file of the scanned values. From my inventory app POV written in VFP, all I do to get the barcodes of all the boxes we scanned is APPEND FROM
JRandomFileName DELIMITED. I don't concern myself with the details of the laser optics, or the wireless Ethernet adapter, or even the Windows CE computer that runs the show...
Feel free to disagree; if you like spending lots of time writing graphics code that doesn't port well, it's your time and effort, and your employer's money.
