PDF Converter not working with Visual FoxPro 9.0

[radu_aanei]

I'm using PDF Converter 2.10 with Visual FoxPro 8.0 and works fine. I'm trying to upgrade the application to Visual FoxPro 9.0 and the same code doesn't work. It doesn't give an error but it produces no PDF file.

Any ideas?
Thanks!

[radu_aanei]

I've tracked the source of the problem and found out from another topic (http://www.amyuni.com/forum/viewtopic.php?t=1021) that the print job name is different in FoxPro 9.0 because it includes full path to the printed report.

It seems that the szLockName parameter of the Lock function and szDocTitle parameter of the SetDocFileProps fuction can't handle a full path (e.g. "c:\default.pdf"). Is that true? Is there another workaround?

Thanks.

[Jose]

Hello,

As you may or may not be aware the value that should be passed to the lock function is the document name as it appears in the print spooler. In VFP 8.0 and previously you would just need to supply the report name.

However in the case of VFP 9.0 it is sending to the print spooler the complete path along with the report name but VFP 9.0 is also removing ":" colons and "\" slashes and adding "_" underscores.

Example:

The "H:\FoxProExample\FoxProExample\PDFConverterActiveX\test.frx" would appear in the print spooler as "H__FoxProExample_FoxProExample_PDFConverterActiveX_test.frx"

Consequently In order to resolve this situation you will need change the value you are passing to the Lock() function. I have included a code snippet below which illustrates this.

Example:
objPDFconverter.Lock("H__FoxProExample_FoxProExample_PDFConverterActiveX_test.frx")

Hope this helps?

[radu_aanei]

Thanks for the reply.

I've tried using your suggestion and it didn't work.

I know the argument of the lock function should be the print job name and I've seen that VFP9 uses the full path of the report as the document name.

But I've seen that VFP9 does not replace ":" or "\" as you suggest. I've printed a document and in the printer's queue the document name was the full path and file name of the report with no replaced characters. I've tried passing that to Lock with or without replacing ":" and "\" but it didn't work.

Any other suggestions? Are there some limitations to what characters the Lock function accepts?

[Jose]

Hello,

What OS are you testing this on? My tests have been on winXP.

Thanks

[AccountView]

Hi,
When working with the locking function and getting the name of the lock right from within VFP, I noticed the translation too.

In the print queue, the name is "c:\temp\folder\name.fxp". The name to use for the lock is at that moment is "c__temp_folder_name.fxp"
Taking the transformation of : and \ to _ in account, the locking works.

What remains is the question, is that the only tranformation? What other characters are transformed?

If amyuni CDINTF.DLL is doing the translation from an unusable printjob name to a usable one (For it is used as a registry entry value, some symbols can't be used), can you please inform us what other transformations are done?

Kind regards,
Timo

[Jose]

hello,

The issue you are encountering occurs because of how the Lock\UnLock() functions handle UniCode characters.

The Lock() function in the current version of the PDF Converter will replace certain "invalid" characters or UniCode characters with "_" (underscores).

Below is a list of the characters that are substituted with "_" (underscores):
\:<>\"/|*?

This situation has been resolved in our version 4.5 that is scheduled for release in the second week of October 2010.

Thanks
Jose

[Aldus@Monitor]

Hello!

I have looked at the cdintf450.h file and Lock/Unlock/SetDocFileProps are still only declared to be ANSI and not Unicode.

Regards

Aldus@Monitor