Hello Dennis,

The most common approach seems to be to use a BarCode font. As long as you're able to properly encode the string and display it on the report in the correct BarCode Font, it works fine. But you run into problems when you're trying to display additional details to the BarCode, like a readable number below the BarCode. Especially alignment of the additional information can be quite a challange.

Another quite common solution is the use of an ActiveX control. The downside is that the control needs to be hosted on a Form, which might not even be available during the reporting process ...

The ActiveX component usually has the ability to render the BarCode to a range of custom formats, that are written to disk after rendering. The range of formats usually consists of a couple of BitMap formats (bmp, jpg) and some vector formats like wmf.

After the disk file has been created there's a wide range of options to ultimately get it's contents displayed on a Picture Object on your report.

One important issue is that to ensure the BarCode is indeed "scannable" is the quality of the BarCode. Especially scaling and compression on BitMap formats may easily render the results unusable. My recommendation would be to always use a vector format like wmf, which is also supported by the Picture Object.

One alternative to the ActiveX solution is the use of a BarCode .DLL. This approach is somewhat more complex to set up, but it does not require a Form to host the ActiveX control. This way you'd be able to generate the barcodes through a .PRG file or even on the fly while reporting using code.

I've been using the .DLL approach for years, using products from dlSoft with great success. I've used this method for simple BarCodes aswell as with the more complex 2D ones like PDF417. The main advantage is that even the complex 2D BarCodes are fully scalable and scan absolutely reliable ...

I've also found the pricing of the dlSoft products to be very reasonable and also the runtime distribution terms quite acceptable.