>Hi Everyone!
>
>I have a question regarding the SET PRINTER TO NAME function.
>
>In previous versions of VFP when we sent a report to a file, we could use an alternate printer driver other than the windows default one by doing this before the REPORT FORM TO FILE command.
>
>

>SET PRINTER TO NAME (gcAlternatePrinter)
>

>
>Now in VFP9 this no longer works. To work around this bug, it has been suggested to do something like this:
>
>

>=SETPRINTER(gcAlternatePrinter)  && VFP 9.0 Fix for SET PRINTER TO NAME bug.
>
>** Replaces SET PRINTER TO NAME which doesn't work in VFP 9 if sending report to a file
>PROCEDURE SETPRINTER
>LPARAMETERS lcSetToPrinter
>LOCAL lcDefaultprinter, oWSHNet
>oWSHNet = CREATEOBJECT('Wscript.Network')
>IF lcSetToPrinter == UPPER("DEFAULT")
>   oWSHNet.SetDefaultPrinter(gcDefaultPrinter)
>ELSE
>   oWSHNet.SetDefaultPrinter(lcSetToPrinter)
>ENDIF
>RELEASE oWSHNet
>

>
>This sets the Windows Default Printer to the Alternate one we need. What worries me is what happens if someone is trying to print something from another application to the default printer at the same time I change this? As a rule, I never like to change user settings outside of my application (even temporarily) unless absolutely necessary as this could result in some major headaches. Also, from what I've read on the internet using WSCRIPT can be iffy on different operating systems too. In fact, we have a client testing this for us who this method doesn't seem to work for.
>
>Is there a DIFFERENT way to handle this VFP 9 bug?
>
>Any help would be greatly appreciated! Thanks!

See http://www.berezniker.com/content/pages/visual-foxpro/changing-windows-default-printer

You're right, there is a potential problem if somebody tries to print from your application and from another application at the same time.

You obviously should restore back the default printer once you've done.