>>>>I having problems with function printsatus()
>>>> where can I find some information about
>>>>an API that does it better ?
>>>
>>>Hi Moises,
>>>
>>>You mean the fact that it always returns .T.? AFAIK, there's no way around this. Using the API it's possible to open the printer, even when it's turned off.
>>
>>You're pretty much right about this; as long as the spooler sits between the app and the printer, PRINTSTATUS() can only report a problem
after it occurs. More detailed control can be obtained by setting up the print drive to prin directly to the printer rather than the spooler, but in VFP, this creates problems of its own, with VFP often reporting a problem connecting to the spooler.
>>
>>Short of writing something that functions at the device driver layer in C/C++, VFP doesn't have any easy way to directly monitor the actual port status. it gets even more complex when network printing becomes involved, since multiple spooler layers may be active, and you might never be able to determine the real port being accessed, or have adequate privileges to see the hardware directly.
>
>Hi Ed,
>
>I wrote a DLL calling GetPrinter() in Winspool.drv to retrieve information from a PRINTER_INFO_2 structure. One of the members of that structure is called Status and, according to the SDK, "Specifies the printer status. This member can be one of the following values:
>
>Windows NT:
>
>PRINTER_STATUS_PAUSED
>PRINTER_STATUS_PENDING_DELETION
>
>Windows 95:
>
>PRINTER_STATUS_BUSY
>PRINTER_STATUS_DOOR_OPEN
>PRINTER_STATUS_ERROR
>PRINTER_STATUS_INITIALIZING
>PRINTER_STATUS_IO_ACTIVE
>PRINTER_STATUS_MANUAL_FEED
>PRINTER_STATUS_NO_TONER
>PRINTER_STATUS_NOT_AVAILABLE
>PRINTER_STATUS_OFFLINE
>PRINTER_STATUS_OUT_OF_MEMORY
>PRINTER_STATUS_OUTPUT_BIN_FULL
>PRINTER_STATUS_PAGE_PUNT
>PRINTER_STATUS_PAPER_JAM
>PRINTER_STATUS_PAPER_OUT
>PRINTER_STATUS_PAPER_PROBLEM
>PRINTER_STATUS_PAUSED
>PRINTER_STATUS_PENDING_DELETION
>PRINTER_STATUS_PRINTING
>PRINTER_STATUS_PROCESSING
>PRINTER_STATUS_TONER_LOW
>PRINTER_STATUS_UNAVAILABLE
>PRINTER_STATUS_USER_INTERVENTION
>PRINTER_STATUS_WAITING
>PRINTER_STATUS_WARMING_UP"
>
>which would seem to be able to tell you what you need (and want) to know about the printer. However, in usage, it always returns 0 (which is none of the above). I even tried calling it directly after a report command directed to the printer and the result was the same.
>
Again, you're talking to the spooler, not the port - the spooler only reports errors after attempting to send characters and something bad happens. What you need is a port monitor, which sits a layer below the spooler interface and can access the port and any status messages queued from the printer.
Another possible problem was the configuration of the port itself - if the port were not set to at least one of the bi-directional options (AT bi-directional, EPP (my general preference) or ECP (when it works)), then no status messages beyond dedicated lines in the pritner interface would be seen. If the printer is on a network, it gets even more complex...your spooler might not see errors caught by the spooler at the machine servicing the printer!
>Of course, this leads us to the question, "Was the DLL working correctly?" Apparently so. Another member of the structure, Attributes, is properly set. I've tested this on several different workstations with different types of printers and the value returned is always correct. Further, note that the only difference in the the functions is the assignment statement for the return value (I've even flip-flopped them with no difference).
>
>Right now, I have no idea as to why this occurs. This value may not be available unless called directly from a device driver.
