Re: POS Printer

See below...
On Thu, 18 Sep 2008 13:02:38 +0300, "vvf" <vvf@xxxxxxx> wrote:

Hi All,

I thought it would be easy to print to a simple POS Printer (Star SP 200,
parallel port) but for some reason it seems really difficult for me. I think
I have all the theory right, but I just can't print correctly text to it.

Here is what I know and what I think is right.

1) I know that in theory, all I have to do is send down to the printer plain
text and some control codes in order to access special features of the
printer (alignment, underlining, etc.) These special codes are non-printable
characters (escape codes.)
****
This certainly works; I have a legacy application which drives an ancient label printer
and it works perfectly through XP
****

2) I am not using the Windows drivers because I know they strip non
printable characters so I am using the "Generic Text Printer" driver which
is supposed to not strip those characters. Is that correct?
****
No. The Windows drivers expect metafiles and GDI interfaces and are essentially
irrelevant to the discussion.
****

3) I simply do the following:

hPort = CreateFile( _T("\\\\.\\LPT1"), GENERIC_READ | GENERIC_WRITE, 0,
NULL, OPEN_EXISTING, 0, NULL);
****
Not clear why you need GENERIC_READ since you are not reading anything from the printer; I
use just GENERIC_WRITE
****

Then, I do a WriteFile(hPort, strContents, iSize, &lpWritten, NULL),

where strContents is a CString containing my string to be sent to the
printer and iSize is (strContents.GetLength() )
****
You *MUST* under these conditions declare the variable as
CStringA strContents;
or you might end up trying to write half of a Unicode string. Whenever you are using
legacy devices in modern C/C++/MFC you must explicitly use the 8-bit character data types,
and not trust CString to give you the correct bytes.
****

I am also doing a FlushFileBuffers(hPort) just to make sure that all
buffered data is written to the port.
****
A good idea, but probably not the problem
****

Since I access it this way, I am assuming that the "Generic Text Printer"
driver is not really neccessary, right ? I mean, I could just remove it from
my Printers and it should still work the same way. Is that correct?
****
I see no reason to be concerned with it at all. I just open LPT1 and send raw escape
sequences. (The printer was purchased in the mid-1980s, still works, and the application
still produces the file with the raw control codes in it...and it isn't worth the effort
to rewrite the app)
****

4) I know that a POS printer has an internal buffer so just because we send
data to it and the data does not fill it up, it will not print anything
unless we send a CR, LF. Otherwise, if the buffer is full, it will
automatically print even if we do not send a CR, LF. ( I have confirmed this
reading the printer's programmer's manual. )
****
My printer works the same way
****

The printer is working fine because I was able to successfully print a test
page from the "Generic Text Printer".
****
But that just translates GDI requests to plain text. It doesn't address your problem
****

Using the theory above, here are my results:

Having installed the "Generic Text Printer", and sending only one printable
character to the printer followed by CR, LF, the "Generic Text Printer"
shows that it receives the Print Job, says "Printed" and then the job
dissapears from the list. Everything OK here, except that the printer does
not print anything. If I try to print again, same result. However, if I
attempt a few more times, without changing anything, then it works and
prints the stuff requested previously as well. So I am assuming that the
buffer gets full and the printer is forced to print. My only conclusion is
that for some reason, it ignores the non-printable characters ?

I have looked in the printer's manual, and I tried to also send escape codes
but they are totally ignored. However, I thought that according to 2), this
should not happen.

I must be missing something because I saw this same printer in action with a
software package and it prints everything very nicely. The only thing is
that the software is very old and probably based on MS-DOS/Win9x. So is my
theory correct ? Am I on the right track ? ... am I missing something really
obvious ?

Thanks for your patience in reading this.
****
My first suspicion is Unicode, only because it has been the source of many similar
problems in the recent past.
joe
****
vvf


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.