Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Print Barcodes on FPW26 form ?
- Thread starter fourletr
- Start date
Some staring information:
Code3 of 9 (or Code39) can be downloaded for free as a Windows font.
In your invoice you may wish for example to have a part no. which is ABC1234 printed as a barcode.
If this part no is held in a database field PARTNO, you will have to now specify the field to be printed as '*'+alltrim(PARTNO)+'*' and specify font for the field as code 3 of 9. The '*' delimiting symbols are needed for the barcode reader.
Your choice of barcode font depends on the data you wish to encode- numbers only, numbers +uppercase characters, or numbers + upper & lowercase characters. Barcodes vary in size and density, and your method of printing and real estate available on your report form, together with the capability of the end user to read the codes will drive selection of symbology.
A laser printer will be able to print small high density codes, while a dot-matrix will not.
Code3 of 9 (or Code39) can be downloaded for free as a Windows font.
In your invoice you may wish for example to have a part no. which is ABC1234 printed as a barcode.
If this part no is held in a database field PARTNO, you will have to now specify the field to be printed as '*'+alltrim(PARTNO)+'*' and specify font for the field as code 3 of 9. The '*' delimiting symbols are needed for the barcode reader.
Your choice of barcode font depends on the data you wish to encode- numbers only, numbers +uppercase characters, or numbers + upper & lowercase characters. Barcodes vary in size and density, and your method of printing and real estate available on your report form, together with the capability of the end user to read the codes will drive selection of symbology.
A laser printer will be able to print small high density codes, while a dot-matrix will not.
It appears as though my previous posting on barcodes utilization
1. what barcode symbology to use
2. what printer technology to use
3. what scanner technology to use
4. etc.
has been deleted.
In lieu of that you might want to look at other general references such as
It will help you understand many of the basics about barcodes and what to take into consideration when making your choices.
Having worked with barcode utilization since the mid-80's I have found that too many people entering into using barcodes just make simplistic (rush-to-an-answer) decisions and then sometimes regret their choices.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
1. what barcode symbology to use
2. what printer technology to use
3. what scanner technology to use
4. etc.
has been deleted.
In lieu of that you might want to look at other general references such as
It will help you understand many of the basics about barcodes and what to take into consideration when making your choices.
Having worked with barcode utilization since the mid-80's I have found that too many people entering into using barcodes just make simplistic (rush-to-an-answer) decisions and then sometimes regret their choices.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Thanks for the replies guys. Sorry for the delay, was sidetracked by another challenge.
Here's the precise scoop. We already print invoices with a UPC number on them using a standard FPW2.6 Report form. These numbers are extracted from a field in a table. All we want to do is to print these numbers as upc-a barcodes. we already have all the necessary technology for reading in place and have used this for years. we understood that you could just get a set of TType fonts and set the report field to this font. However it seems this doesn't work since the barcodes produced this way cannot be read. Some of these invoices have several hundred items on (Music CDs for public libraries) so we need a simple conversion facility that will just read the upc from the table and print a scanable barcode.
Are we expecting too much ??
Richard Myers
Newton Myers Consultants
Here's the precise scoop. We already print invoices with a UPC number on them using a standard FPW2.6 Report form. These numbers are extracted from a field in a table. All we want to do is to print these numbers as upc-a barcodes. we already have all the necessary technology for reading in place and have used this for years. we understood that you could just get a set of TType fonts and set the report field to this font. However it seems this doesn't work since the barcodes produced this way cannot be read. Some of these invoices have several hundred items on (Music CDs for public libraries) so we need a simple conversion facility that will just read the upc from the table and print a scanable barcode.
Are we expecting too much ??
Richard Myers
Newton Myers Consultants
"the barcodes produced this way cannot be read"
Barcodes not being read can be the result of a variety of issues.
* Poor print quality
* Poor contrast ratio between dark & light areas
* Insufficient barcode reader sensitivity
* In-accurately formed barcode
* For some code symbologies - Missing or inaccurate checksum digit
* Etc.
Is it unreasonable/unrealistic to expect you to be able to print 'Readable' UPC-A barcodes onto a form?
Absolutely not.
However UPC barcodes have a few more complexities to them than do "Code 3 of 9" (Code 39) barcodes. Most notably the presence of a Checksum digit as the last digit.
You might want to look at
Whenever I launch into a barcode implementation project I set myself up with a simplistic test setup - A keyboard 'wedge' interface attached to both my workstation keyboard and to a barcode reader.
In that way, barcodes read will appear on my workstation screen as manually typed-in characters. I then test things in some simplistic manner by Reading and then displaying them in NOTEPAD or WORD, not necessarily in FP.
If I attempt a READ and nothing shows up, there is a problem in either printing of the barcode or in reading it. I resolve those problems FIRST.
Then once I KNOW that the barcodes are printed both accurately and in a readable manner, and that my reader will actually successfully READ them, then I can go forward to utilize the barcode read within the FP/VFP application.
Once you have the Print/Read issues worked out, you can easily print them using your existing FP Report Forms by merely, within the Report Form, launching a UDF which will change Fonts for the Barcode section and then launching another UDF to return to the default font.
NOTE - Due to barcode height typically being different than character-type height, you might also have to issue some paper positioning commands to return to the original location before resuming printing of the remainder of the report.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Barcodes not being read can be the result of a variety of issues.
* Poor print quality
* Poor contrast ratio between dark & light areas
* Insufficient barcode reader sensitivity
* In-accurately formed barcode
* For some code symbologies - Missing or inaccurate checksum digit
* Etc.
Is it unreasonable/unrealistic to expect you to be able to print 'Readable' UPC-A barcodes onto a form?
Absolutely not.
However UPC barcodes have a few more complexities to them than do "Code 3 of 9" (Code 39) barcodes. Most notably the presence of a Checksum digit as the last digit.
You might want to look at
Whenever I launch into a barcode implementation project I set myself up with a simplistic test setup - A keyboard 'wedge' interface attached to both my workstation keyboard and to a barcode reader.
In that way, barcodes read will appear on my workstation screen as manually typed-in characters. I then test things in some simplistic manner by Reading and then displaying them in NOTEPAD or WORD, not necessarily in FP.
If I attempt a READ and nothing shows up, there is a problem in either printing of the barcode or in reading it. I resolve those problems FIRST.
Then once I KNOW that the barcodes are printed both accurately and in a readable manner, and that my reader will actually successfully READ them, then I can go forward to utilize the barcode read within the FP/VFP application.
Once you have the Print/Read issues worked out, you can easily print them using your existing FP Report Forms by merely, within the Report Form, launching a UDF which will change Fonts for the Barcode section and then launching another UDF to return to the default font.
NOTE - Due to barcode height typically being different than character-type height, you might also have to issue some paper positioning commands to return to the original location before resuming printing of the remainder of the report.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Thank you for your prompt and comprehensive reply. However this really doesn't solve anything for us. We are familiar with most of what you suggest and infact use barcode scanning on a daily basis. We have both keyboard wedge and USB scanners installed but we are still at a loss as to how to convert data within a FPW table field (character format) into a printed and readable barcode. We printed our trial barcodes at 600 dpi on a laserjet printer and tried various sizes, all to no avail.
"Once you have the Print/Read issues worked out, you can easily print them using your existing FP Report Forms by merely, within the Report Form, launching a UDF which will change Fonts for the Barcode section and then launching another UDF to return to the default font."
What UDF pray ??
Sorry to be a bit thick, but this is legacy software written by someone else so we are struggling a little.
Richard Myers
Newton Myers Consultants
"Once you have the Print/Read issues worked out, you can easily print them using your existing FP Report Forms by merely, within the Report Form, launching a UDF which will change Fonts for the Barcode section and then launching another UDF to return to the default font."
What UDF pray ??
Sorry to be a bit thick, but this is legacy software written by someone else so we are struggling a little.
Richard Myers
Newton Myers Consultants
"What UDF?"
Actually, now that I had paid attention to the fact that you are using FPW instead of FPD, you should not need a UDF.
If you have the UPC-A Fonts installed within Windows, you should be able to configure your FPW Report Form to utilize these fonts by changing the Font of the Report Form's Textbox which will print the barcode.
Let's begin by examining the value stored in your FP table.
How many digits is it?
10
11
12
If it is not 12 digits then it is not totally complete to meet the UPC-A needs.
The first digit is the UPC number system digit related to the type of product (0 for groceries, 3 for drugs, etc.).
The next 5 digits are the UPC manufacturer's code.
The first five digits of the right half are the product code.
The final digit is the check digit.
Again if it is not 12 digits it needs to be made to be 12 digits in length - paying special attention to calculating a correct checksum digit for the last digit.
Let us know if you are OK up to that point.
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Actually, now that I had paid attention to the fact that you are using FPW instead of FPD, you should not need a UDF.
If you have the UPC-A Fonts installed within Windows, you should be able to configure your FPW Report Form to utilize these fonts by changing the Font of the Report Form's Textbox which will print the barcode.
Let's begin by examining the value stored in your FP table.
How many digits is it?
10
11
12
If it is not 12 digits then it is not totally complete to meet the UPC-A needs.
The first digit is the UPC number system digit related to the type of product (0 for groceries, 3 for drugs, etc.).
The next 5 digits are the UPC manufacturer's code.
The first five digits of the right half are the product code.
The final digit is the check digit.
Again if it is not 12 digits it needs to be made to be 12 digits in length - paying special attention to calculating a correct checksum digit for the last digit.
Let us know if you are OK up to that point.
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Yep! All stored UPC numbers are 12 digit. These correspond to the barcode numbers on the back of 99.999% of CDs. We use these in-store to scan at the check-out and when ordering or receiving CDs. Scanning the item places the 12 digit upc code into the relevant field in various tables. In this particular case the upc field of the line item table for the invoice. This is normally generated by actually scanning the barcode on the product. When printing the invoice we extract the UPC number and print it, but now we need to print a readable barcode instead of the number. Not exactly "rocket science" but we just can't see where to get the correct font from.
Richard Myers
Newton Myers Consultants
Richard Myers
Newton Myers Consultants
I guess that we'll tackle this one step at at time....
I used to use the Wasp Barcode Label program for an off-the-shelf solution but it was a stand-alone product and did not integrate to FP/VFP.
For the sake of continued testing, have you tried downloading one of the "Trial" copies of a barcode label printing program? There should be a ton of them to download out on the web.
Within the off-the-shelf Label program manually enter one of your FP table's 12 digits barcodes.
NOTE - you might have to tell the program that you already have the check digit. If you can't do that, leave off the last digit.
Now print out the label and test its readability.
Now within FPW create a test Report Form with the barcode textbox font set to your UPC Font. Set it up and print the same 12 digits to paper. Don't forget to make the textbox field long enough or it might truncate the print-out.
Now compare the two supposedly 'exact' same barcodes - visual comparison as well as readability.
Let us know.
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
I used to use the Wasp Barcode Label program for an off-the-shelf solution but it was a stand-alone product and did not integrate to FP/VFP.
For the sake of continued testing, have you tried downloading one of the "Trial" copies of a barcode label printing program? There should be a ton of them to download out on the web.
Within the off-the-shelf Label program manually enter one of your FP table's 12 digits barcodes.
NOTE - you might have to tell the program that you already have the check digit. If you can't do that, leave off the last digit.
Now print out the label and test its readability.
Now within FPW create a test Report Form with the barcode textbox font set to your UPC Font. Set it up and print the same 12 digits to paper. Don't forget to make the textbox field long enough or it might truncate the print-out.
Now compare the two supposedly 'exact' same barcodes - visual comparison as well as readability.
Let us know.
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Hi again:
Ok, I've had limited success with your suggested testing. I downloaded WASP and despite it's protestations was eventually able to enter/copy/paste a readable barcode. I then pasted this into a 'dummy' report, printed the report and lo and behold it scans and if I enter a dummy product to match the upc, it looks it up.
This was done by entering only 11 digits as the upc and also the WASP demo would only accept digits up 4 !!
However it did sort of work. Now how on earth can I do what I want to do, namely extract a series (sometimes a few hundred) UPCs from the UPC field the line item DBF and print them on the invoice?
BTW I am so grateful to you for spending so much time on this seemingly simple process, it's driving me NUTS!!!!
Kindest regards
Richard Myers
Newton Myers Consultants
Ok, I've had limited success with your suggested testing. I downloaded WASP and despite it's protestations was eventually able to enter/copy/paste a readable barcode. I then pasted this into a 'dummy' report, printed the report and lo and behold it scans and if I enter a dummy product to match the upc, it looks it up.
This was done by entering only 11 digits as the upc and also the WASP demo would only accept digits up 4 !!
However it did sort of work. Now how on earth can I do what I want to do, namely extract a series (sometimes a few hundred) UPCs from the UPC field the line item DBF and print them on the invoice?
BTW I am so grateful to you for spending so much time on this seemingly simple process, it's driving me NUTS!!!!
Kindest regards
Richard Myers
Newton Myers Consultants
Well we seem to be making some progress, albeit slowly.
Admittedly I have never used the Wasp Trial version. I used the full version a number of years ago.
If the Wasp Demo won't let you print all digits, then I'd suggest looking for another Barcode Label demo.
Most off-the-shelf barcode label programs will calculate the UPC checksum digit themselves when UPC is specified. That is most likely why you had to enter only 11 digits.
I am a little confused on what you did when you "pasted this into a 'dummy' report, printed the report".
What I had intended for you to do was to use the off-the-shelf label program to directly print out a UPC label to paper via the same printer that you intend to use for your FP application.
Then I had intended for you to create some temporary FP data table which you would use to 'feed' the FP Report Form test. In that temporary data table you would have a field containing the same character string that you used in the off-the-shelf program. And in your Report Form you would have specified that the Font for the Barcode's textbox would be your UPC font.
NOTE - you might have to try this FP Report Form test with both the 11 digits and then again with the full 12 digits since the 'raw' UPC fonts most likely will not automatically calculate and print your checksum digit for you.
At this point you should have at least 2 different printouts.
1. UPC Label printed with off-the-shelf program
2. UPC Label printed with FP application's Report Form
You might also have another printout if you used both 11 digits AND 12 digits within your FP Report Form testing.
Now with the various printouts, you can compare them both visually and with the Barcode Reader. Any differences noted should point you towards the problem.
Let us know how this test works out.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Admittedly I have never used the Wasp Trial version. I used the full version a number of years ago.
If the Wasp Demo won't let you print all digits, then I'd suggest looking for another Barcode Label demo.
Most off-the-shelf barcode label programs will calculate the UPC checksum digit themselves when UPC is specified. That is most likely why you had to enter only 11 digits.
I am a little confused on what you did when you "pasted this into a 'dummy' report, printed the report".
What I had intended for you to do was to use the off-the-shelf label program to directly print out a UPC label to paper via the same printer that you intend to use for your FP application.
Then I had intended for you to create some temporary FP data table which you would use to 'feed' the FP Report Form test. In that temporary data table you would have a field containing the same character string that you used in the off-the-shelf program. And in your Report Form you would have specified that the Font for the Barcode's textbox would be your UPC font.
NOTE - you might have to try this FP Report Form test with both the 11 digits and then again with the full 12 digits since the 'raw' UPC fonts most likely will not automatically calculate and print your checksum digit for you.
At this point you should have at least 2 different printouts.
1. UPC Label printed with off-the-shelf program
2. UPC Label printed with FP application's Report Form
You might also have another printout if you used both 11 digits AND 12 digits within your FP Report Form testing.
Now with the various printouts, you can compare them both visually and with the Barcode Reader. Any differences noted should point you towards the problem.
Let us know how this test works out.
Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
Since writing my previous message I have received a reply from Elfring Fonts. Inc. together with a link to their Demo programme. This works in a much better way than the Wasp one and I've so far printed a 'scanable' barcode of an actual CD which works just fine and is readable. This demo also gives me the text string that is used to generate the barcode and I will try pasting this into the table and see what happens.
Slowly, slowly catchee monkey !!
Again many thanks.
Richard Myers
Newton Myers Consultants
Slowly, slowly catchee monkey !!
Again many thanks.
Richard Myers
Newton Myers Consultants
- Status
