>Hi,
>
>I am using VFP5a and a receipt printer. Is there any know reliable method of checking and testing whether the printer is okay/out of paper or jam before printing to it.
>
>The functions : sys(13) and printstatus() does not help much as it is unreliable.
>
>Please advise me or recommend to me which Win32 API allow us to do that. Thank you
There is no simple solution to directly check the printer status without resorting to something that examines the port directly called a port monitor, written using the Win DDK. Using a specialized driver and not treating the device as a printer is the best approach if you need to check physical port status. A brief explanation from the MSDN library follows:
Port Monitors
A port monitor is responsible for the communication channel between the spooler and the printer device. It supports one or more types of communication channels. For example, the Windows NT default port monitor, localmon, supports parallel, serial, and file ports.
To be able to print to a physical printer, Windows NT requires that the printer be connected to one or more ports that are controlled by port monitors. A port represents the destination for the data being sent to the printer.
Windows NT supplies five port monitors: Port Monitor (DLL)
Supported Communication Channels
Local (localmon.dll)
Parallel and serial ports; files.
Macintosh (sfmmon.dll)
Network adapter card, via AppleTalk protocol, by which an AppleTalk print server or print device is accessible.
Digital (decpsmon.dll)
Network adapter card, via DECNet or TCP/IP, by which a DEC print device is accessible.
HP (hpmon.dll)
Network adapter card, via DLC, by which an HP JetDirect DLC print device is accessible.
LPR (lprmon.dll)
Network adapter card, via TCP/IP, by which an LPD print server or print device is accessible.
The Windows NT Resource Kit contains a high level overview of the supplied monitors. Vendors need to develop a port monitor if their printing device connects to a different type of I/O port, such as a SCSI or Ethernet LAN port.
If you need a detailed explanation, it's chapter 14 of the NT DDK (Graphics Drivers/Design Guide/Part 3: Print Components.) You may be able to purchase a COM solution that can manage the interaction for you. As an example, if you're willing to give up the use of the GDI tools and talk to devices on a low-level basis, you could use the MSCOMM32 ActiveX control to handle devices on serial ports; it gives you direct control of the port and the ability to interact bidirectionally and check control line statuses.
