We just released a new version of our program that includes saving DataWindows to PDF using the new NativePDF feature. It has been working fine for us in testing, but a number of users are reporting getting error messages that indicate that the dw.SaveAs(filename, PDF!, FALSE) method returned -1 (failure).
We definitely included pbpdf170.dll in the installer, putting it into the program's application directory along with the other PB dlls.
Any ideas why this might be happening? We don't know yet whether it is all users or just some users.
We do know that the filename it is saving to is valid - it was selected with a File Save dialog box that wouldn't allow invalid paths.
Is there any debugging possible - further information from the NativePDF functionality about what the problem is?
I'd hate to have to quickly just turn this feature back off! (We do install a separate PDF printer driver with the app anyways, for use in other situations that the NativePDF stuff can't handle, so it fortunately wouldn't be a big deal to turn it off.)
Thanks.
I'm puzzled about a temp file being written someplace that might be a common directory. What happens if it's a network share with dozens of users creating PDF files? The individual files might all be unique, but the temp file name will be common among all of them.
Wouldn't it be better to create the temporary file within the users own appdata directory structure? Or even to create the file with a guaranteed unique filename?
If there are multiple users trying to generate PDF simultaneously, it will first check if the name of the filename_temp.emf is open or not, if yes, a sequential number will be added to the file name (e.g. filename_temp(1).emf, filename_temp(2).emf etc.) to differentiate it from the existing ones. Of course should there be any changes the final release shall prevail.