When I use direct_print to print to the local printer (parm1 of START statement is "") it creates a spool file that is "printing" in the print spooler, but it never prints. In some cases, it cannot be cancelled either. We have had to de-install the hardware and re-install it in order to clear the print job.

Has anyone else come across this? And if so, is there a solution?

Wayne

I should add that printers connected to a COM port are fine. The printers I am having trouble with are connected by USB port or some other bizarro thing.

Wayne

I have not had a problem but all of my Direct_Print experience has been to print to a networked printer. Are you sure there is an associated "STOP" to close the session?

HTH,

John

Just thought of something… is this a Windows only printer? If so then neither DOS or direct print will work. Some printers can only print using OS drivers. The way to test this is to go to DOS and send plain text to the printer and see if it prints. Chances are you have one of those printers.

Only option is to replace the printer with a more robust solution.

HTH,

John

I'm sure they are "windows-only" printers. Direct_Print writes to the windows default printer when no printer name is sent in the START parameter. It goes through the windows print spooler so I don't see why this would be a problem.

Wayne

Because there is no real way to convince windows that the print job is done (other than maybe exiting OI or restarting the spooler). In AREV, you could suspend out to DOS (and sometimes a PDISK PRN would do it), so that windows finally figured out that the print job is done.

You might try a timeout on the printer settings (if it allows it), but that can mess up fonts as well.

We're in OI here. The spooler does seem to think the print job is done, because it does, in fact, start printing. The status of the print file within the print spooler is "printing", that is. The printer never actually prints anything.

Then, when you try to cancel the print job, it sits there "deleting - printing" until you disconnect the cable, delete the printer from the Printers window and reboot the computer and reinstall the hardware.

Wayne

]

Yes and no - you are doing DOS printing (ie, raw text not handled by the windows print drivers) from inside OI instead of AREV. But it still isn't "windows printing" and windows only printers won't print anything as a result.

Just means windows saw the print output and sent it to the printer (it doesn't wait until done unless you change the flags). The printer looks at the text stream and discards it (thus, no print). The print job stays stuck because Windows never figures out that you are done (as it often did with AREV print jobs unless you jogged it a bit by starting up a copy of command.exe).

And never will with direct_print and windows only printers. Direct_print is there mainly to support old dot matrix printers and print jobs that sent escape codes directly to printers (such as needed for secure check printing hardware and various special applications) and those who had elaborate (but text) solutions to printing and don't want to re-write them (plus, it helps with AREV32, no doubt). What it won't do is fix a windows only printer (those cheap ones tossed in free with consumer grade computers running non-business operating systems) so that it can accept a raw print stream. These printers are cheap mainly because their print logic was moved into the windows print drivers and direct_print (and AREV and any command redirect to a printer port) bypasses this.

Karen is exactly right. I have seen this behavior before when a client went out and bought a deal on a new printer. They could print fine from Word, Excel etc. But from DOS no way. The job would appear in the queue and it would look like Windows sent it to the printer but nothing printed.

The problem with these "Windows-only" printers is they need the printer driver to convert the print job into something that the printer can understand. When you send text to a printer it has to have built-in smarts that convert those characters into printed output. In the old days those "smarts" were built into the printer. Within the past 5 years or so you could buy printers where those "smarts" are now contained in software within the printer driver.

When you use Direct_print it is bypassing the portion of the printer driver that would change the print data. Actually, that is the whole purpose of direct_print to send data exactly as the programmer intended.

The only way to solve your problem is to replace the printer or rewrite the job in OIPI.

John

Phoooey.

Wayne, I would revert back to John's response which I do not see answered here. The problem is usually that the direct_print stop command has not been issued. This is similar to using a printer on command without a printer off.

Sorry. The Direct_Print Stop command was issued. The problem apparently that it is a windows-only printer. I am rewriting the routine with OIPI, as noted in a later posting.

Wayne

View this thread on the Works forum...