Problem with Amyuni PDF when printing 1

[BenAir]

Hi,

My system uses the Amyuni PDF converter to produce PDF's - this is carried out programmatically. Intermittently my client has a problem in printing a report (NOT to a pdf) whereby a dialog box pops up asking for a pdf file name. It's as if the pdf converter is set as the default printer (when the user WOULD be asked for a pdf file name):however, it's not!

Has anyone else seen this type of behaviour, and what workaround is there?

Many thanks.

 

[Mike Lewis]

BenAir,

It's as if the pdf converter is set as the default printer

Could it be that the PDF driver name has become embedded in the report file as the default printer?

If you are using VFP 9.0, open the report in the report designer, and look for a tick against Printer Environment in the Report menu. If the tick is there, remove it and save the report.

In earlier versions, you have to open the FRX file as a table, and remove the contents of certain fields. This is a well-documented technique. See, for example,

http://www.ml-consult.co.uk/foxst-12.htm

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[JRB-Bldr]

All the things that Mike says above are very valid possibilities. Try to do as he suggests first and evaluate the results.

Another possibility is that the settings of your PDF driver are being lost/modified.

For our own PDF 'printing' I have found that instead of having the PDF 'printer' write its output to a differing file name in possibly a differing location each time, it is better to set the driver to output to a single un-changing file name in a single un-changing directory. In that way, the VFP automation does not have to attempt to modify the PDF driver settings.

Once the PDF document is written then VFP will MOVE the known file in the known directory to another location and rename it to whatever is desired. At that point anything else can be done with it - we send out 100's of PDF email file attachments per day in this manner.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

Another thought came to me...

Does your client ever intentionally (or un-intentionally) use the Amyuni PDF converter to print their own documents totally separate from the VFP application?

If so they might be changing the parameters of the PDF 'printer' and thereby introducing this problem.

If that were the situation, I might suggest using a totally separate PDF "printer" for your VFP application with a printer name such as "VFP-PDF-ONLY" so that the user will not use it for their own purposes.

You could use another instance of the same PDF print driver or another one of the many offered on the web such as:

http://www.bullzip.com/products/pdf/info.php

(NOTE: Since this is the 2nd time in as many weeks that I have referenced this product on this forum I should say - I have absolutely no connection with this company or its product. It is merely that I have personally used it and it has worked well for me.)

Good Luck,
JRB-Bldr

 

[BongoB1]

Have you submitted this question to the Amyuni support staff? We have been using the Amyuni Converter Professional version in VFP applications for several years with very good results. When I've had problems, I've found the support staff very helpful, especially when I've shared my code with them. It maybe something as simple as the syntax you're using in the code to reset the default "printer" once the .PDF has been generated.

 

[BenAir]

Thanks to everyone for their input here - lots of ideas to try!