>>>>>>>>>Hi Fred,
>>>>>>>>>
>>>>>>>>>>Is there any way to get the VFP current printer, since it may have been changed from the WINDOWS DEFAULT?
>>>>>>>>>
>>>>>>>>>Create report tmp from sys(2005)
>>>>>>>>>Use tmp.frx
>>>>>>>>>? expr
>>>>>>>>>When you create a report, VFP stores the current VFP default printer in the Expr field.
>>>>>>>>>
>>>>>>>>>Christof
>>>>>>>>
>>>>>>>>Thanks, Christof. I had done it that way in the past, but I had forgotten about it. We had switched from that way to just using REPORT x TO PRINT PROMPT, but that does not keep the changed printer for the next time you print. I know if we want to change VFP's default printer we can use SET PRINTER TO NAME xxxxx from the array returned by APRINTERS and then PROMPT will use the new default.
>>>>>>>>Do you know of any way to find out the printer that was set using the PROMPT option?
>>>>>>>
>>>>>>>Could you use =SYS(1037) dialog instead of PROMPT. Fox should keep that setting.
>>>>>>
>>>>>>Hi Ed,
>>>>>>
>>>>>>OK, but now how do you know if they hit
or Cancel and don't want to print? How do you handle that?
>>>>>
>>>>>SYS(1037) just allows to select a printer. Actual printing is still handled by REPORT FORM ... (no prompt), i.e. you may include menu option 'print setup' where user will invoke SYS(1037) and make/change printer selection for whole application.
>>>>
>>>> That's one way to do it. We wanted some way to show the user where the report was going to go BEFORE they ran it, so that's why we used the PROMPT option for REPORT.
>>>
>>>You can still use:
>>>***cmdPrint.click event
>>>=SYS(1037)
>>>REPORT FORM myreport TO PRINT
>>
>>The problem there is that if they cancel out of the SYS(1037) there's no way to not do the printing. With the PROMPT option, if they hit cancel, the report does not print.
>
>Yes, because SYS(1037) is called 'Print Setup Dialog', i.e. user either changes the setting or not, but still prints. You can insert one more messagebox() to really 'cancel' printing, or just explain your users that they are looking in wrong place.
That won't fly. We used to have a custom DLL that we used in 2.6 that got the current printer by playing games with the visable property on the Setup Dialog thru the API. However, that DLL no longer works in VFP, so we can't use it. Our users are used to seeing where the output is going before they print, and having the option to cancel the printing before they print.
