>>>
>>>I don't think there is a way to absolutely be sure, even going through the Win API. The report could spool to the printer and Windows would think it printed.
>>
>>There are ways to do this, but it involves spooler interaction through the API, and it gets complex when networked printers are involved. Bela Bodecs produced an FLL that changed the name of print jobs, so he obviously accessed the spooler interface, as File#9319, and he provided source, so this might be a good place to start...
>
>Seems to me that you still can't guarantee that it will always work. The printer will have to provide that information back to the OS. I know, for example, that our HP 4 will hold several pages in memory, but the OS thinks that print job is complete, when in fact it isn't.

Hi Craig,

People have to remember that Windows doesn't work anything like DOS did in terms of its relationship with a running application. To paraphrase Ivor Horton in one of his C++ books, "In DOS, the application is the dog and the OS is the tail. The OS wags when told to. In Windows, the OS is the dog and it's the application that wags." FWIW, even if the printer is turned off, it's perfectly possible for the API to open a port to it.

A couple of months ago, I started playing around trying to write a DLL that would return the printer status. While I could get a lot of information about the printer, its status (Ready, Off-Line, etc.) wasn't one of the things I could get. Ed and I had a number of private discussions as to exactly why this is the case. Apparently, even Windows doesn't know or care about the status until it tries to send a print job.

I did have the thought that perhaps you could monitor the system tray to determine if the printer icon was active. However, as you mentioned, with printers these days having the capacity to hold several pages in memory, even that wouldn't be an accurate indicator. In fact, I've printed a single page, walked over to the network printer, come back (page in hand), and the printer icon was still active in the system tray. Further, monitoring the system tray isn't directly possible in VFP, since the API call involved requires the address of a callback function.

My conclusion on these sort of issues is: "The view ain't worth the climb."