Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved dw.SaveAs NativePDF returning failure (-1)

  1. Issue
0
Votes
Undo
  1. Daniel Vivier
    Daniel Vivier
  2. PowerBuilder
  3. Tuesday, 14 November 2017 21:37 PM UTC

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.

  1. Build
Migrated app from PB 12.5 to PB 2017 Build 1681 an...
CREATE USING syntax in a .NET Assembly
Responses (3)
Arthur Hefti
Arthur Hefti Accepted Answer Pending Moderation
  1. Wednesday, 15 November 2017 04:54 AM UTC
  2. PowerBuilder
  3. # 1

Hi

We use Process Monitor to find out what really happens under the hood: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

Create a filter for your process and you can see e.g where PB tries to write the files or registry values are read. Maybe you have to compare the logs from one installation where it runs fine with one with problems.

Regards
Arthur

Comment
There are no comments made yet.
René Ullrich
René Ullrich Accepted Answer Pending Moderation
  1. Wednesday, 15 November 2017 07:07 AM UTC
  2. PowerBuilder
  3. # 2

Powerbuilder writes a file (dwPage.emf) to the applications installation directory if you export PDF (native).

Maybe that a missing write permissions to the applications installation directory causes that the export fails.

Comment
Daniel Vivier
  1. Daniel Vivier
  2. Wednesday, 15 November 2017 12:39 PM UTC
That's ridiculous, the application's installation directory shouldn't necessarily be writeable, except by Administrative users, and application programs shouldn't have to be run as Administrator. We moved away from doing that (running the app with Administrator privileges) years ago because it was not a recommended practice!

  1. Helpful
Daniel Vivier
  1. Daniel Vivier
  2. Wednesday, 15 November 2017 13:45 PM UTC
I see that there is a bug open for this behaviour (several actually, one is https://www.appeon.com/standardsupport/search/view?id=418). It says there that there will likely be a fix in a release by the end of the year, where the required temp file (which they say they are renaming to filename_temp.emf) will instead be written into the folder that the PDF file is being generated in, which then should of course be writeable. Very annoying for now though!

  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 15 November 2017 13:57 PM UTC
  2. PowerBuilder
  3. # 3

Hi Dan;

  This is an issue where the application user does not have write permissions to the App's installation folder. The NativePDF feature creates an interim .EMF file in the Apps' EXE location during the construction of the final PDF. Appeon has an open ticket for this issue and this will be fixed in the PB2017R2 release in December. The fix will see the .EMF work file created in the same folder as the outputted PDF file is to be saved. Also, the interim .EMF file will be cleaned up at the end of the PDF save - whereas today, the .EMF work file is left in the PB App's install folder.

HTH

Regards ... Chris

Comment
Brad Mettee
  1. Brad Mettee
  2. Wednesday, 15 November 2017 14:08 PM UTC
Chris,



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?

  1. Helpful
Roland Smith
  1. Roland Smith
  2. Wednesday, 15 November 2017 14:41 PM UTC
Writing of the .emf file is likely why NativePDF is even slower than GhostScript. It should be holding the data in memory.

  1. Helpful
Shenn Sellers
  1. Shenn Sellers
  2. Wednesday, 15 November 2017 16:38 PM UTC
In the Bug Tracking system, it states...





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.

  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.