Hi Kevin,

I just run a quick test and VFP9SP1 respected the current VFP printer set with SET PRINTER TO NAME for REPORT FORM TO FILE with REPORTBEHAVIOR 80 and 90.
Did you uncheck Printer Environment when you saved report? Can you provide repro code/steps?
Are you running VFP9 SP1 or SP2?


>
>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!