>i have an app that prints both Dot Matrix draft mode, bypassing windoze printing using ???, and also, in the same app, printing in windoze mode with getprinter(). In one part where i have a VFP report (as apposed to one layed out with ? and ??), where i say 'repo form myrepo to printer prompt noconsole'. All works acceptably in W98 or W95. W2k - not on your life! If the printer you choose with getprinter() is not the default printer i get a message saying 'error loading printer driver'.
This usually indicates that the Windows printer driver is not configured properly for the named printer; it may be that the printer is competing with another printer that uses a common DOS device name, or temporary problems with free space in the GDI - often, repeatedly retrying and trapping the error, and retrying will let it work. Also, the use of the NAME clause is preferable under NT/2K; checking if you run under NT or 2K and using the preferred syntax sometimes helps. Before changing the code, other things can present the same symptoms.
One thing I do is to use the Wscript.Network object's SetDefaultPrinter method to switch which printer is the current default, and just print to the default printer all the time. See the WSH refs in my signature, or the articles that George Tasker and I wrote for VFUG (
www.vfug.org) for details.
If the printer is set to the default printer - it prints. With 'repo form inv to printer prompt noconsole' absolutely nothing happens.
This is specifically solved by using the WSH Wscript.Network object to reassign the default printer; get the desired printer name, set the default to it, adjust the print properties with SYS(1037) and go.
With the Dot Matrix printer, everything seems to go into the twighlite zone until you quit the app - then it prints everything out at once! I might be living way back in the past, but i somehow think there may still be a few folks out there using DM printers for multi-part documents - why does uncle bill make it so difficult to use them??
It's not - it's a Windows spooler behavior. The spooler is likely set not to release the job to print until the spool job is closed, and the spool job remains open until another is started. I use a sequence like:
SET PRINTER TO NUL:
EJECT
SET PRINTER TO
to force the current stream closed, a stream to the bit bucket to reset the printer status, and back to the default. I also print to a file and use CopyFile() to send it to a specific device whenI want to completely bypass the GDI; write the stream to a file, and copy the file to the device, and the spooler never steps in.