Hi,
In the past I have created an automatic document workbench, which processed dozens of MS-Word documents and at the end created automatically PDF from.
To control the Path and Location of the PDF-storage without any questions, dialogs etc. I have programmatically manipulated the registry for the "PDF-XChange Printer 2012" for the current user, particularly the key Profiles\Current\Save: "ShowSaveDialog", "Path", "File", "WhenExists", "RunApp" just before I called printing ( something like "setRegistryForPDFXChangePrint(); wrd_doc.PrintOut(...)" ).
Everything was great and worked for many years (2012-2014).
Currently, after a period of non-usage of this method and having current "PDF-XChange Printer 2012" (5.5 Build 315) I observe that this method doesn't work anymore. In detail: the setting of the Path and File is fine, but the dialog for Storage Location and overwrite existing file are shown despite the proper values in the registry which shall prevent their display. So my No-Dialogs/No-Questions process need user interaction now...
My investigation lead to the impression that the driver doesn't re-read the values "ShowSaveDialog", "WhenExists", "RunApp" from the registry just at the beginning of its work, but uses some values cached during the profile definition in the printer setting dialog. The values of "Path", "File" are read properly, however.
My question is, have any changes been made to the printer driver since 2013 which may cause the behaviour described? Shall I have to give the printer driver some additional "hint" (in form of a registry key value), to let re-read / re-interpret the "ShowSaveDialog", "WhenExists", "RunApp" ?
Alternatively: how may I easily tell the "PDF-XChange Printer 2012" printer (manipulating the registry) to use a particular predefined, named profile for printing? This could be a viable solution too, as using a special profile having these options disabled (lets call it "AutoDocPrintNoDialog) in conjunction with setting Path/File via registry leads to a proper result.
Regards
Piotr
Controlling PDF Printing via registry SOLVED
Moderators: TrackerSupp-Daniel, Tracker Support, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Tracker Supp-Stefan
- Will - Tracker Supp
- Site Admin
- Posts: 6815
- Joined: Mon Oct 15, 2012 9:21 pm
- Location: London, UK
- Contact:
Re: Controlling PDF Printing via registry
Hi Piotr,
Thanks for the post - I'm afraid that our end user products were never meant to manipulated in this manner, so you would need to use our Drivers API SDK:
https://www.pdf-xchange.com/product/pdf ... rivers-api
Apologies if that's not what you wanted to hear, but I hope that helps.
Thanks for the post - I'm afraid that our end user products were never meant to manipulated in this manner, so you would need to use our Drivers API SDK:
https://www.pdf-xchange.com/product/pdf ... rivers-api
Apologies if that's not what you wanted to hear, but I hope that helps.
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Re: Controlling PDF Printing via registry
Hi,
I feared this answer (no, not really "feared" ). This means simply that it worked by "accident" until now using an unsupported way.
I fully agree with your conclusion. I'll start a purchase process.
Thank you anyway
Regards
Piotr
I feared this answer (no, not really "feared" ). This means simply that it worked by "accident" until now using an unsupported way.
I fully agree with your conclusion. I'll start a purchase process.
Thank you anyway
Regards
Piotr
- Tracker Supp-Stefan
- Site Admin
- Posts: 17908
- Joined: Mon Jan 12, 2009 8:07 am
- Location: London
- Contact: