barcode39.i
I have a legacy client running V11 chui. They have some code that produces bar codes using an old Progress include file {barcode39.i}.
Recently it was discovered that a . (period) is being read through the code as a - (dash) so they contacted me for some help.
I determined that the variable that holds the binary code equivalent of the characters had the same value for . and for -.
010000101 /* . */
010000101 /* - */
So I figured finding the correct code and replacing it would work. I see that the correct code for . is 100101000 so I replaced that in the code.
The scanner does not read . at all now.
I am hoping someone out here uses the barcode39.i include file and has had better luck with it. If so, can someone/anyone update me on how to fix this issue.
I have attached the barcode.i code.
Thanks so much,
Ross Anderson
nosredna@cogeco.ca
| Attachment | Size |
|---|---|
| barcode39.i | 6.55 KB |
- Login to post comments
Code 39 or Code 128?
Hi Ross,
Is your client generating Code 39 or Code 128 barcodes with this include? I'm asking because it offers two internal procedures.
Assuming that you need help with the "bar-code-39" procedure, I have done a little investigation and here's my 2 cents:
- the variable kod has the initial value of "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ.? *$/+%-", so the "." character is in the 36th position
- the variable att has a bunch of binary values as its initial value, I suppose they are sorted in the same order as the ASC chars in "kod"
- the variable kk receives your input string and surround it with asterisks - for example, *input string*
- when the procedure loops through the "kk" string, it calculates the binary value for every character of your input string. So, when it finds the "." character, it does the following:
--- assign jj = index (kod, substring (kk, ii, 1)) * 9 - 8 ---> assign jj = 36 * 9 - 8 ---> jj = 316
--- wk = substring (att, jj, 9) + "0". ---> wk = substring(att, 316, 9) + "0" ---> wk = "011010000" + "0" ---> wk = 0110100000
After all this logic, it converts the binary value stored in "wk" to Code 39 barcodes. However, looks like it's getting the wrong binary translation, because you stated that the "." character has the binary 100101000, but the procedure is getting 011010000.
I'm not really sure if I got it right, but seems to me that your problem is going around this.
Hope if helps!
Regards,
Yuri