Check if a printer is working.

Hi all,

I need to write a program that can check if there is a printer connected to the LPT1 (or other) port before sending data to it. Do you know if C or C++ already have a function that does this?
My problem is that :

Nope, no general way.
The parallel port is not only used for printers, so just because there is any device attached to it, you should not start sending printer data.

Some printers support a protocol for identification, but some donŽt.

You can stat() the printer "port" first. Are you really writing a DOS program? I mean DOS, not windows console(!)...
If it is a windows program, youŽll have a powerful and completely different interface to the printer driver instead of talking to the printer directly.

If you know the printer you are using ,they usually have the device driver definitions which can be used to talk and print on printers. It helps you to identify the printer, check for response. That is how I have programmed for printing on serial ports.

Thanks! I'm programming with Dev-C++ in console application mode. I supose this is windows console not DOS.
My program does not need to be 100% general as it is developed for a customer who will have a printer in the LPT1(or LTP2). The only thing I need to know is if the printer is on-line and ready or not to avoid the program hanging. Should I know in advance the printer model or there is a standard check protocol?

Most printers donŽt use the "LPT" adressing scheme anymore. It is optional today. But since you asked for it:

The printer port usually is located at port 0x378 for LPT1. To make sure you got the right port number, read the memory at 0040:0008 - 0040:000f (arranged in 16bit WORDs for LPT1-4).

The base address, weŽll use 0x378 here, is the data port used to send and receive data.
base+1 (0x379) is the status/interrupt register and base+2 (0x37A) is the control register.

To find out if a printer is connected and ready to print, you need to read from 0x379 and check:
- bit 3 (error)
- bit 4 (select)
- bit 5 (out of paper)
- bit 6 (ack)
- bit 7 (busy)
I donŽt know the values you get for a connected or disconnected printer, youŽll find out with a short test program and plugging the cable in and out.

Even if you got that, we have a big problem: You are writing a windows program and all NT based versions donŽt allow you to access ports directly. Same for the memory reading process above.Thus you have to use the windows printer driver or compile as 8bit DOS program.

I'll try to learn a bit about printer devices in Win32. I'd never programmed using the windows API but I suppose I'll manage to get throught. And I'll tell you about the results. Maybe you'll learn something, I will for sure.

What I've find out do far.

Hi all,

Let's continue. What I've found is the following. Using the windows.h library you have acces to all the information about the installed printers. First of all there is EnumPrinters(bla, bla,bla) that gives you a list of tha available printers and some info about their status (current status as far as windows is concerned not the real one). Then with functions as OpenPrinter, StartDocPrinter,StartPagePrinter and WritePrinter you can send data to the printer. Then, if the status of the printer has changed and the system was not aware it will update this status. Unfortunately he does it after you call the function so, up to now, i don't know ho to check in "real time" the status of a printer. Well, I see that in fact this message does not solve the problem but at least sets the right context. I'll continue searching and trying things.

The short answer is that you don't check to see if the printer is ready. You let the operating system handle that. I haven't played with windows device contexts in several years, but I recall that there is a return value from the function that dumps your device pallete to the printer, and this value will tell you whether printing worked or not.

I also recall that it's a huge thing to learn, but the results I got were really impressive. Most importantly, they required me to know almost nothing about the printer itself (although all positioning and length calculations have to be scaled for the resolution of the printer). The beauty is that writing to a print-preview screen is identical to writing to the printer. I found this hard to beat.

I see, you're right. In the end I've given up on writing directly to the printer. Now I follow the AddJob, WriteFile way and let the user or the OS manage that the job is really printed or not.
Thanks again everybuddy for the answers.