Link to home
Start Free TrialLog in
Avatar of rstone
rstone

asked on

Generic Text driver adds a CR?

I'm trying to print to a thermal label printer.  It takes text commands, so I normally just Open LPT1 for Output and print.  It works fine.  I now need to use a Generic Text driver, but when I do, a Carriage Return gets added after my first line!  My code is this:

Open LPT1 for output as #1

For X = 1 to 10
   Printer.Print Trim(Str(X))
Next X
Printer.EndDoc

When I set my default printer to my generic text driver, I get this:

1CRCRLF2CRLF3CRLF4CRLF5CRLF6CRLF7CRLF8CRLF9CRLF10CRLF

CR is a Hex 0D and LF is a Hex 0A.  Basically, I'm getting an extra CR at the end of myfirst line.  What's going on and how can I stop it?  I'm running this under Windows98.  Will it be different under Windows95, Windows NT, or Windows 2000?
Avatar of GivenRandy
GivenRandy

Try using:

Format$(X)
This seems like a problem I had at one time when using the Generic Text driver. I'm thinking that I had to end the PRINTER.PRINT statement with a semicolon and explicitly concatenate any carriage returns and line feeds that I wanted.

So, if you want one carriage return:

Printer.Print Trim(Str(X)); Chr(13);
After each print a CR is written unless you use a trailing ";"
I think it's better to keep printing lines, thus use:

Open LPT1 for output as #1

DIM hlpLine as String

For X = 1 to 10
   hlpLine = hlpLine & (Str(X))
Next X
Printer.Print hlpLine
Printer.EndDoc

Nico
Avatar of rstone

ASKER

When I try to put everything into a string, I still get the same result:

Printer.Print "1" Chr(13) & Chr(10) & "2" Chr(13) & Chr(10)

etc.

I still get:

1CRCRLF2CRLF3CRLF4CRLF5CRLF6CRLF7CRLF8CRLF9CRLF10CRLF
Just a thought:
Try to open the print-file AS BINARY.
Avatar of rstone

ASKER

I'm not opening the print file, though.  If I use OPEN "LPT1" for Output as #1, it works fine.  I need to use the print driver, that's why I need to use Printer.Print.
What happens when you use:
Printer.Print "1" Chr(10) & "2" & Chr(10)

It does appear that the "Generic Text" driver is sending CRLF when it receives a LF.
Avatar of rstone

ASKER

It's interesting.  When I try:

Printer.Print "1" Chr(10) & "2" & Chr(10)

It shows up as a CRLF.  Same thing when I try:

Printer.Print "1" Chr(13) & "2" & Chr(13)

I could live with this if it didn't put the extra CR on the first line. Is there a replacement Generic Text driver somewhere?  How hard is it to write one?
The last time that I actually played with the "Generic Text" driver was probably with Windows 3.1 but I may have also worked with it under Windows 95. It's difficult to remember as the company employed me at the time had not yet converted to Windows 95 but I had it installed on my PC.

Unfortunately, I don't have access to the Windows NT CD at work to install the "Generic / Text Only" driver. However, I do remember that there were configuration options with the driver to set things such as "Add LF after CR", etc. I wish I could give you explicit instructions.
Avatar of rstone

ASKER

I can't find anything configurable in the driver that looks like it would do that.  I have paper source set to Continuous, Letter size, no separator page.
rstone,

Both:
Printer.Print "1" Chr(10) & "2" & Chr(10)
and
Printer.Print "1" Chr(13) & "2" & Chr(13)
work.

Why not add the first line as a string in front like:
Printer.Print strLineOne & Chr(10) & "1" & Chr(10) & "2" & Chr(10)

BTW did you search for the specific thermalprinter driver?

I use a label printer but I just send a straight format Form to it in the right size (from-size) and have no problems.
You could display one or more text fields with the escape codes added to it.

Giving some idea's ?

Nico
Avatar of rstone

ASKER

It doesn't seem to matter what I do.  No matter what I always end up with an extra CR at the end of the first line.  I have tried what you suggested about putting it all on the same line and it still happens.
Again but slightly different:

Why not add the first line as a string in front like:
Printer.Print strLineOne & "1" & Chr(10) & "2" & Chr(10)

In other words: did you perhaps included a CHR(13) in strLineOne ?

I'm always supersticiuos !

Nico
Avatar of rstone

ASKER

There's no way that I'm including the extra Chr(13) in my string.  I've tried everything I can think of.

I tried what you just suggested and made sure that I'm not including a CR, and the extra CR still appears.  Could you check it out on your system?  I've run the same code from work and home and I get the same result.
Just being lazy: Can you zip (the trouble part of it) and mail to my nico5038 hotmail.com account!
ASKER CERTIFIED SOLUTION
Avatar of LeReveur
LeReveur

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of rstone

ASKER

Adjusted points from 100 to 200
Avatar of rstone

ASKER

OK, that actually worked.  Is there any way for me to modify that section programatically?  The point of using the Generic Text driver is so the the end user can easily install it.
There probably is a way to modify that section programatically using the Windows API. Unfortunately, I don't have that information at hand to give you the code. However, there are a couple of options for you. The first option is to write an installation document that includes screen prints for clarification of the instructions. The second option is to further modify your working "Generic / Text Only" driver by renaming it to something more meaningful. Then you can give a copy of your modified driver to the user to install.
Avatar of rstone

ASKER

How can I give a copy of my driver to the user?  That would be great.
Sorry I haven't been able to respond right away. After looking into how to copy the driver, it seems more involved than I had originally thought. You can export part of the registry but I'm not familiar with which sections would need to be exported. I would hate to tell you what sections to export only to miss something. I hope you can get help from someone else on this aspect.
Avatar of rstone

ASKER

I have actually figured out a solution to my problem.  I forgot where I got it, but I found some VB code that uses the Windows API to open a driver and print raw data to it.  Now it doesn't matter what actual driver is being used because the raw data just goes to where the driver is pointed, but the driver doesn't interpret it.