Author: Ted Roche
Posted: 2005-04-12 at 09:30:03
For those tuning in late to the thread, a recap of the situation, and
some new symptoms:
Our clients (several) have purchased and deployed the PDF995 Suite. It
is a very nice solution to some complex problems, and we plan to stick
with it. Thanks for all of the alternate suggestions, but most were
considered and rejected. We are using some INI file programming in
other parts of the application, to produce uneditable, 128-bit
encrypted PDFs with great success, even over Terminal Services.
This app is running in VFP7 and using the Mere Mortals framework. Using
code based on that framework, the report requestor dialog has been
modified to give them a "Save to PDF" feature along with Print,
Preview, Export to Excel, Export to HTML, and a few others.
When the client selects the PDF output, just before issuing the REPORT
FORM command, we use the SET PRINTER TO NAME command to switch the
current VFP printer to PDF995. We've commented out the code that resets
the printer back to the originally selected one, and we do see the
PDF995 printer selected as SET("PRINT",3) at the end of the run. We've
also added various timeouts, as mentioned in the OP, below, with no
change.
Sometimes we get a PDF, sometimes it prints out on the (Windows
default) laser printer. It's not every-other-time, sometimes a batch
prints okay, sometimes the first one fails. No pattern discerned yet.
NEW INFORMATION: when we copy-and-paste the routine that issues SET
PRINTER from the code running before the report and add it to the
Report's Data Environment Init(), the report prints out PDFs, every
time (in the first several dozen tests, at least). Go figure. We'd
prefer not to have to copy-and-paste this code into dozens of reports,
but you do what you have to do to get the job done.
Insights, inquiries and comments welcomed.
On Apr 11, 2005, at 6:20 PM, Ted Roche wrote:
> We've got a vertical niche app running in VFP 7, and have coached the
> clients through installing PDF995 as a printer driver and it is
> working very well for them to pick manually from a REPORT FORM TO
> PRINT PROMPT situation. Now, we'd like to be able to offer them the
> ability to print to a PDF as part of a pre-report dialog.
>
> Basically, the code is picking the PDF995 printer from the list in
> APRINTERS() ('cause some workstations have 'PDF995' installed and some
> 'PDF995Share') and issuing a:
>
> SET PRINTER TO NAME lcPrinter
>
> In the Debug window we are seeing SET("PRINT",2), the windows default,
> stay the same, and SET("PRINT",3), the VFP currently selected printer,
> switch to the PDF995 printer. That command is followed by a REPORT
> FORM TO PRINTER.
>
> Sometimes, it generates the PDF. Sometimes it comes out the Windows
> default printer.
>
> We've tried throwing in various time delays (WAIT NOWINDOW TIMEOUT and
> DOEVENTS()) with no change.
>
> Reports are all stripped of printer information.
Ted Roche
Ted Roche & Associates, LLC