Hi!
As the title suggests, I noticed that the last version that honors the "OpenViewer" setting (using the COM interface) is 3.2.2.
Newer version (tested on 3.3.2 and 3.5.x) simply don't show the PDF once the .Convert() method has finished.
Any help?
Thank you
Hi,
are you sure it is COM related?
The more common cause is PDFCreator can no longer find the default PDF viewer.
Does setting the path to the viewer through the GUI (once) fix the issue?
Best regards
Robin
Hello and thanks for the quick answer!
I did several tests with PDF viewers:
I changed the Windows default from Adobe to Chrome and vice versa.
I have modified the PDFCreator default viewer.
Nothing has changed...
My VB6 program opens the produced PDF only if I go back to version 3.2.2. This happens on different PCs.
The log is of version 3.5.1. (last part of the conversion)
PDFCreator-3.5.1.txt (2.2 KB)
Hi,
thanks for the feedback; I was able to reproduce the issue and will create a ticket to get this fixed in one of the next updates.
Best regards
Robin
Hello Mr. Robin,
are there some updates?
I'm having the same problem.
Thanks,
Marco
This still does not work in 4.0.1. Also is there more detailed documentation for COM interface? .chm help that comes with the installation is ridiculous.
Hi,
the help file should contain all required information and is also available as html version here: https://docs.pdfforge.org/pdfcreator/3.5/en/pdfcreator/com-interface/
While the setting is currently still disabled for the COM workflow, you should now get a warning that the setting doesn't exist.
Is there a specific reason why you'd like PDFCreator to call the default application for opening the created document, instead of directly doing this from code?
I can happily reopen the ticket and discuss this with the rest of the team.
Best regards
Robin
Hi,
Yes, after I googled the problem I eventually found out that the .chm help is the same as online help but the search does not work at all (you can’t actually search for anything ). I don’t need this property as long as the default behaviour is to not open the viewer. I’m setting this property to false because some users somehow had the viewer automagically open after the creation of .pdf. Anyhow, it would be nice to have that level of control, so I hope you’ll bring it back.
Thank you and best regards,
Tomislav Pavlović
But the documentation still show OpenViewer as an option!
We have been using the "OpenViewer" = false property as well for years and with latest version exceptions are being thrown while it is still listed in the documentation. As well it always was a very use setting for us.
Could someone please clarify if this is an error in the release or in the documentation?
Cheers,
Sven
Another hand coming up for this. My client uses PDFCreator in terminal server and they are moving to a new server so I've installed a trial. They have 200+ Excel workbooks with a macro I wrote for them that exports a workbook to a secure PDF (the reason the bought PDFCreator). It now throws an error for every workbook. That's a lot of updating to do...
Might downgrade to the older version. Is it still available for download? (Later - yes it is fortunately)
It would be better if the OpenViewer property was still there so at least this line wouldn't throw an error in legacy code:
PrintJob.SetProfileSetting "OpenViewer", "false"
Breaking change for no real reason?
Just bumping this to see if the bug above has been fixed in later versions? We're specifically not upgraded due to this breaking change.
Hi Rob,
May I ask which version of PDFCreator Terminal Server is currently in use/which version was used during the trial?
I would need to speak to our developers.
Brgds
Sascha