We get the "Save as..." dialog!

[kenbla]

Hello, we have a problem when creating PDF documents from a Delphi environment.
We currently run our application on an application server which runs Windows Server 2000 SP 4 and this works fine, but we are about to move to Windows Server 2008 (64 bit) and have performed some tests. When we try to create a PDF document using PDFXChange from the Delphi application it doesn't work the same way as before. The user now gets a "Save as..." dialog with a default PDF name of "blank"! We don't want to use the "Save as..." dialog at all. How do we get rid of it?
The application code has not been changed at all. Is there anything we must change in the code in order to get it to work as we want it (i.e. without the Save as dialog)?
The new Windows 2008 Server has PDFXChange v. 4 installed whilst the old server (the one that works) has v. 3 installed. Is this a problem?
The application was developed using v. 3 a couple of years ago.

Any help is greatly appreciated!

[Tracker Supp-Stefan]

Hello Kenbla,

While I have no knowledge of the ver3 Drivers API SDK, the ver4 one has a ShowSaveDialog boolean value (default True), which you can set so that no save dialogue is shown to the end user. And yes as there are some changes between the two, you might need to make minor changes to your code as well.

Please refer to Section 3.1.2.14 Save in the Drivers API SDK manual.

Best,
Stefan

[kenbla]

Thanks Stefan, we have tried to set that boolean to false but it doesn't help I'm afraid!
I only have access to SDK manual for version 3! What kind of code changes are we talking about?

[Tracker Supp-Stefan]

Hello Kenbla,

What kind of code changes are we talking about?
Only the dev guys can answer in details to this question, but the manual for the new SDKs shoul dbe included in the download package available on our website:
https://www.pdf-xchange.com/product ... rivers-api

Please have a look at it, and try it out, and if unable to resolve this yourself, we might ask you to provide a stripped down sample, so we can have a look at the code you use for the save step, and will be then able to advise further.

If posting samples to this forum make sure no keys are left in the code.

Best,
Stefan

[kenbla]

Thanks Stefan. I work on the development team with Delphi applications and I have not installed PDFXChange and I don't know if we have installed the SDK for version 4, I can't find the SDK manual anyway!
We have another team that does the installations! Is it possible that they have only installed the PDFXChange printer driver and not the SDK? Is it two separate installations that should be run?
I have looked in Windows Explorer and it has the following folders under C:\Program\:
Tracker Software and its four subfolders: Live Update, PDF Viewer, PDF-Tools 4 and finally PDF-XChange 4. That's all we have on the application server.
When I look through these folders I find some manuals but none of them contained the section you asked me review (3.2.1.14)!
We only use PDFXChange to create PDF document from a Delphi environment we don't use it from Word, Excel etc.
When version 3 was installed it created.

[Tracker Supp-Stefan]

Hello Kenbala - the whole manual is 815Kb - so here it is.

I am also attaching a DriverAPI Ver4 Delphi sample.

Best,
Stefan

[kenbla]

Thanks a lot Stefan. I will try to find a solution to my problem from the manual you provided me!

[John - Tracker Supp]

Ok thanks - please come back if you still have issues.

[kenbla]

Hello again,
I still haven't found out how to get rid of the Save dialog. I have looked in the code in the example you sent me
and it looks similar to the code we currently have for version 3 at least when it comes ShowSaveDialog. Please have a look
at my code below for version 3:
"
try
oReg.RootKey := HKEY_CURRENT_USER;
sKeyPath := 'Software\Tracker Software\PDF-XChange 3.0\Drivers\Control\' + IntToHex(oMessage.lParam, ;
if oReg.OpenKey(sKeyPath, TRUE) then
begin
oReg.WriteString('Save.FullFileName', msSparaPath + '\' + string(msSparaFilNamn));
oReg.WriteString('Save.ShowSaveDialog', 'No');
oReg.WriteString('Save.WhenExists', 'Overwrite');
oReg.WriteString('Compression.Graphics', 'Yes');
oReg.WriteString('Compression.ASCII', 'No');
oReg.WriteString('Compression.Text', 'Yes');
oReg.WriteString('Compression.Color.Method', 'Auto');
oReg.WriteString('Compression.Indexed.Method', 'Auto');
oReg.WriteString('Compression.Mono.Method', 'Auto');
oReg.WriteString('Fonts.Embedd.All', '1');
oReg.WriteString('Save.App.Run', 'None');
//oReg.WriteString('Save.App.Run', 'Default');
sKey := 'XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX';
oReg.WriteString('Reg.Key', sKey);
sKey := 'PDFX3YYYY';;
oReg.WriteString('Reg.DevCode', sKey);
oReg.CloseKey;
end;
finally
oReg.Free;
end;
"

When this code runs in version 3 we don't get the Save dialog but in version 4 we get the SaveDialog!
Any suggestions?

[Ivan - Tracker Software]

Hi, it is because you should not use the registry to control V4 driver as you did in V3 however instead of these, you should use driver's ActiveX in V4 as described in the documentation and shown in the examples.

Please investigate these and if you still have issues having fully investigated the examples - please come back with any specifics you may need help on.

[kenbla]

Thanks for your response. It sounds as if we have a lot of work to do in order to get it to work then!
A couple of more questions though:
- Do you know if version 3 of PDFXChange works in Windows Server 2008 (32 bit)?
- Do you know if version 3 of PDFXChange works in Windows Server 2008 (64 bit)?
Have a nice weekend!

[Tracker Supp-Stefan]

Hello kenbla,

Ver 3 is 32 bit only, and will most certainly cause problems on the x64 version, so using ver4 is highly advisable.

Best,
Stefan

[kenbla]

OK thanks! I hope you have time to answer an additional question before we start to implement v. 4!
We are currently (v. 3) using the following PDFXChange functions/methods:

• PXCp_AddWatermark
  PXCp_Init
  PXCp_ReadDocumentW
  PXCp_GetPagesCount
  PXCp_llGetPageCount
  PXCp_InsertPagesTo
  PXCp_WriteDocumentW
  PXCp_CreationDisposition_Overwrite
  PXCp_Write_Release
  PXCp_Write_NoRelease
  PXCp_Delete

Do you know if there are any changes even to these functions from a programmers point of view?

[Lzcat - Tracker Supp]

xcpro40 API is almost same as in V3, except fixed bugs and added new possibilities, so this should not limit you - in most cases your code will remain same, except you will want to add support of new encryption method.

[kenbla]

Thanks a lot for a quick reply!

[Tracker Supp-Stefan]

[kenbla]

Hello again, I tried to compile the Delphi example you so kindly provided, but it doesn't compile! I'm missing the module PXCCOMLib_TLB.pas. The example is set up to search for the file in E:\Program Files\Borland\Delphi7\Imports.
I have searched my entire C: drive but can't find the file! First of all we run Borland Developer Studio 2006 if that makes a difference. Do you know where can I find this file?
I have installed PDF-XChange 4 API.

[Tracker Supp-Stefan]

Hello kenbla,

Please have a look at the Readme file in the Drivers API folder, and follow the steps there.

Also have a look at this topic, where Bob Dukes has explained how he worked around some issues with VS2010.

Best,
Stefan

[kenbla]

Hello, I have now installed PDFXChange version 4 and the SDK.
I have also been able to run the Delphi example that you provided. The Deplhi example works fine to create pdf
documents for plain text and Word documents BUT it doesn't work when I try to create a pdf file from a .html file in a browser component!
It creates a pdf file but it is corrupted and if I look at the properties for the created file it says that it is pdf version 0!!
When I try to open the created pdf document with Adobe Reader I get a message like this:
"The document could not be opened since the filetype is not supported or the file is damaged (for example if it was sent by
email as an attachement and not decoded correctly"!
The funny thing is if I in the Delphi example choose to start Acrobat Reader (Save.RunApp = true) directly from the application when the file is created it looks great! and if I save a copy of that file from Acrobat Reader using the Save as... dialog, the copy can be opened with Acrobat Reader without problems! whilst the original pdf file cannot be opened after I close Acrobat Reader. It seems as if there is something missing when the file is closed or released from the application. I have also tried it in my own application and it's the same problem unfortunately!
Is there a limit on trial version when it comes to creating pdf files from a browser?

[Tracker Supp-Stefan]

The only limitation of the Trial version are the "DEMO" seals added to each page.
So this behaviour needs to be checked. I will speak with Ivan about this.

Best,
Stefan

[kenbla]

I have run additional tests and the created .pdf documents are still corrupt!
I have viewed the created file with Notepad and it seems as if the file is an .html file and not a .pdf file!! I tried to attach the file but it was rejected by this site as "a possible attack vector". Anyway the file is created by PDFXChange version 4 from an .html file in a browser component and should have been saved as .pdf document! The code in my version of the program is very similar to the code in your Delphi example. Your Delphi example gives the same result when the .html conversion is used!
I have run the program in debug mode and I know that the following code is used when the file is created. The code looks like this:
mPDFPrinter.SetAsDefaultPrinter;
mbIsPXCPrinterDefault := true;
mPDFPrinter.Option['Save.RunApp'] := True;
mPDFPrinter.Option['Save.File'] := msSparaFilNamn;
mPDFPrinter.Option['Save.SaveType'] := 'Save';
mPDFPrinter.Option['Save.ShowSaveDialog'] := 'No';
mPDFPrinter.Option['Save.WhenExists'] := 'Overwrite';
mPDFPrinter.Option['Compression.Graphics'] := 'No';
mPDFPrinter.Option['Compression.Text'] := 'No';
mPDFPrinter.Option['Fonts.EmbedAll'] := False;
mPDFPrinter.Option['Saver.ShowProgress'] := True;
if bwrPrint.ReadyState = READYSTATE_COMPLETE then
begin
bwrPrint.ExecWB(OLECMDID_PRINT, OLECMDEXECOPT_DONTPROMPTUSER);
end;
GENMsgdlgUnit.MessageDialog('The PDF-file is created in your Export folder', mtInformation, [mbOK], 0);
mPDFPrinter.RestoreDefaultPrinter;
mPDFPrinter := nil;
mFEventSink := nil;

How is this possible?

[kenbla]

Hello again, I have run som more tests this morning and I think that the problem is that PDFXChange tries to "save" the .html file by issuing this command:
bwrPrint.ExecWB(OLECMDID_PRINT, OLECMDEXECOPT_DONTPROMPTUSER);
I guess that this command starts a separate session which might take some time to run and it "prints" to the printdriver that should point to the PDF- XChange 4.0 driver. The problem (I think) is that the application program including your Delphi example restores the print driver in the mean time to the normal default printer and the ExecWB session instead prints to a normal printer and not the PDF-XChange driver!
Is there a way to start the ExecWB session and "force" the application to wait until it has finished?

[Tracker Supp-Stefan]

Hi Kenbala,

I have asked for some help from the dev team, and hope to get an answer soon.

Best,
Stefan

[Ivan - Tracker Software]

Hello again, I have run som more tests this morning and I think that the problem is that PDFXChange tries to "save" the .html file by issuing this command:
bwrPrint.ExecWB(OLECMDID_PRINT, OLECMDEXECOPT_DONTPROMPTUSER);

PDF-XChange is a printer, how it can save your html ?

Can you say the URL you are opening in the browser and trying to print ?

[kenbla]

PDF-XChange is not a printer but I know that it is a printer driver which can be used to save .html pages by sending the .html page to the printer driver using ExecWB. We have used version 3 earlier but since it doesn't work on a 64 bit server we have to get version 4 instead. The code in version 4 is a bit different though.
I have tested the Delphi example that you provided and it can also save any .html page to a pdf file using ExecWB. The problem I'm having right now is that ExecWB runs in a separate session/thread and the application "resets" the printer driver to the normal/default driver before ExecWB has executed (especially if it's a big .html page)! Can this assumption be correct?

[kenbla]

Hello again, I finally got it all to work!
Thanks for all your help!

[Paul - Tracker Supp]