PDFPFactory.Printer gets COMException

[Bob Dukes]

Hi – I downloaded version 4.0181 of your PDF-XChange Drivers API product to evaluate it before buying. Both your VB example and a simple test case I created get a COMException when PDFPFactory.Printer is called.

Here’s the simple test case:

Public Class PDF
Dim PDFPFactory As New PXCComLib.CPXCControlEx
Dim WithEvents PDFPrinter As PXCComLib.CPXCPrinter

Private Sub Pdf_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
'pdfprinter = PDFPFactory.Printer("", "PDF-XChange 4.0 Sample", "<REG CODE>", "<DEV CODE>")
End Sub
End Class

Private Sub btPDF_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btPDF.Click
prt = PDFPFactory.Printer("", "PDF-XChange 4.0", "<REG CODE>", "<DEV CODE>")
End Sub

COMException message: Error HRESULT E_FAIL has been returned from a call to a COM component.
The error code returned by the COMException is -2147467259.

I’m running a 64 bit version of Windows 7 using VS2008 with all the latest patches. I do have a licensed version of PDF-XChange 4.0 Lite installed as well the evaluation copy of the PDF-XChange Drivers API. Any help you can give me would be appreciated. I’d love to use Drivers API in an application I’ve developed, but can’t evaluate anything until I can get past this exception. Thanks for your help.

[Paul - PDF-XChange]

Hi bob,

thanks for posting this on the forums as well as your email to support. I will make sure that this thread is integrated into the Support Request RT#126

thanks

[Ivan - Tracker Software]

I need to have some further information iof possibel pelase to assist in tracking down this problem :

1) did you use the .exe or .msi installer to install the driver (e.g. PDFX4SA_SM.exe) ?
2) are there pxccom.tlb file in the same folder where pdfSaver4.exe is located (by default, they should be located into C:\Program Files\Tracker Software\PDF-XChange 4 folder).
3) please try to run in this folder:

Code: Select all

pdfSaver4.exe /Quit
pdfSaver4.exe /RegServer

and check if the problem still exists.

thanks

[Bob Dukes]

HI Ivan

1) I used the PDFXAPI.exe that was contained in the PDFX4API.zip download
2) The files installed at C:\Program Files(x86)\PDF-XChange 4 API. There is a folder there called pdfSaver which contains among other things pdfSaver4.exe and pxccom.tlb. I referenced the tlb file in test case to resolve the COM references.
3) I ran pdfSaver4.exe /Quit and pdfSaver4.exe /RegServer from the location in answer 2 above and retested. I still get the COMException.

Just so you know, my licensed copy of PDF-XChange Lite 4 which works fine installed at c:\Program Files\Tracker Software\PDF-XChange Lite 4.

Thanks for your help

[Bob Dukes]

HI Ivan
Ivan - oops, here are corrected answers for 1) and 2)

1) I used the PDFX4API.exe that was contained in the PDFX4API.zip download
2) The files installed at C:\Program Files(x86)\Tracker Software\PDF-XChange 4 API. There is a folder there called pdfSaver which contains among other things pdfSaver4.exe and pxccom.tlb. I referenced the tlb file in test case to resolve the COM references.
3) I ran pdfSaver4.exe /Quit and pdfSaver4.exe /RegServer from the location in answer 2 above and retested. I still get the COMException.

Just so you know, my licensed copy of PDF-XChange Lite 4 which works fine installed at c:\Program Files\Tracker Software\PDF-XChange Lite 4.

Sorry - Bob

[Ivan - Tracker Software]

Hm.
It is odd, because it should be installed in C:\Program Files\Tracker Software\PDF-XChange 4 - standard "Program Files" folder for 64-bit application.

Can you please download end-user PDF-XChange 4.0 driver (not lite), install it, and check if the problem still exists ?

This would be the correct file for the API SDK - distribution file you would install for your users :

www.tracker-software.com/PDFX4SA_SM.zip

Further -I would suggest you 'delete' from your Printers list any existing PDF-XChange Printer - other than PDF-XChange Lite you may have (note: not uninstall as this will remove the Drivers API SDK and examples too)

HTH

[Bob Dukes]

Ivan,

Besides the files PDFX4API.exe installed at C:\Program Files(x86)\Tracker Software\PDF-XChange 4 API, it also installed a full unregistered PDF-XChange 4.0 printer. I was able earlier to print a test page that had your watermarks by going to control panel- printers and devices, right clicking it's icon, selecting printer properties and then Print Test Page. I will delete that printer as you suggested and re-install a printer using the download you indicated, the try the my VB app again. Will let you know in a little while - Bob

[Bob Dukes]

Ivan,

That did it. I'm able to get past the COMException. Thank you very much. I'm still using the pxccom.tlb file PDFX4API.exe installed at C:\Program Files(x86)\Tracker Software\PDF-XChange 4 API\pdfsave in my VB test app. I'll start expanding the test app and then integrating it into the application we want to release. Will let you know I have any more problems. If you have time, could you explain why what we did resolved this? - Bob

[John - Tracker Supp]

Hi Bob,

Its not 100% clear here to be honest - the reason I added to Ivans message the express instruction to use the file : PDFX4SA_SM.exe, was a concern that the driver included in the SDK download was not installing correctly or updating an incorrect previous install.

We are checking the full SDK download to ensure that the SDK installer does correctly install/update any previous driver install - thats my best guess - but Ivan thinks it could just be the 'alignment of the stars' was just more favourable

Rest assured we will check the downloads today to ensure all is well.

[Bob Dukes]

Ivan, John - I integrated the driver API into the application we want to release. The debug module under VS2008 ran without a hitch so I built a release version using my VS2008 set up project. I then used the resultant .msi file to install the release version. The install had no errors, but when I ran the release version from the install directory, it crashed with a message indicating it couldn't find Interop.PXCComLib.dll. I knew that VS2008 put the same application .exe it wrapped in the .msi file in the bin directory of my project. I tried running that and it ran perfectly. The difference turned out the application directory that .msi installed into did not contain a copy of Interop.PXCComLib.dll and the VS2008 bin directory did. I then edited my set up project to include Interop.PXCComLib.dll in the application directory, rebuilt the release version and re-installed using the new .msi file. That solved the problem. My project has other references to assemblies including other Interops and they all get included in the application directory by the .msi file without having to tell the set up project to specifically include them. Is the above normal behavior or an artifact of what we had to do to get around the COMException? I've got another small machine with just an operating system on it that I'll try a clean install using your distributable and an .msi file of my application without editing the set up project. Probably won't get to that till tomorrow. One stupid question - How do I (in vb) get to the return value of an IPXCPrinter method such as AddSMTP Server? - Thanks, Bob

[John - Tracker Supp]

Hi Bob,

The issue you have with Interop.PXCComLib.dll is we believe not related to PDF-XChange as such - but your .NET installation - please ensure you have the latest updates installed and advise.

With regards the MSI installer - we would recommend you pair our MSM modules with your own 'tailored' .MSM file that gives you the desired control/flexibility.

Here are the MSM module links - I note they are currently not listed on our downblaods page - which I will ensure is corrected shortly.

x86 module
https://www.pdf-xchange.com/Driver_MSM_x86.msm

x64 module
https://www.pdf-xchange.com/Driver_MSM_x64.msm

Hope this helps

[Bob Dukes]

John - There is nothing wrong with my .net installation It's got all the latest patches. Your API documentation states:

"We provide a comprehensive installation executable for developer's to distribute with their application and this is the ONLY method authorised for distribution, re-engineering or disassembly of the installation package provided is specifically and absolutely prohibited. Our installer contains all the required driver options required for all versions of Windows from Windows 2000 through to Vista 64 - and all points in between, both 32 and 64 bit!

Developers may either pack the provided installer within their own installation package - or provide separately and simply call from their own installer script using the extensive command line switches provided below.

The latest PDF-XChange Driver for redistribution purposes is always available from our web site - here.
Or from this link : www.tracker-software.com/PDFX4SA_sm.zip

Please note - it is a required that you use the above installer and do not attempt to reverse engineer or de-compile and create your own - if you are not willing to adhere to this specific condition - you should not use the PDF-XChange Driver within your application."

I had planned on using the downloadable Redistributable file on the PDF-XChange Drivers API SDK page, and don't understand why now you're suggesting an alternate method. Can you clarify the difference between using the redistributable file or using the two MSM modules? Also, if I use the MSM modules instead of the redistributable file, does this mean that I need to provide two installations - one for x86 and one for x64?

Could you also answer my question about how do I (in vb) get to the return value of an IPXCPrinter method such as AddSMTP Server? - Thanks, Bob

[John - Tracker Supp]

Hi Bob,

Firstly at the time of writing the help file section on redistribution we did not offer an MSI/MSM distributable - hence the comments regarding using PDFX4SA_SM.exe - however - the same sentiment applies - you must use our redistributable - the difference being we now offer MSI/MSM options.

> why now you're suggesting an alternate method
Using the .MSM modules simply provides a “more native” alternative as you are already creating an MSI package for your own product - whether you use the exe or MSM based option is your choice - however - it was made as a flexible alternate suggestion - not a 'Diktat'

> does this mean that I need to provide two installations - one for x86 and one for x64

If Your application is 32 bit only then the .exe may be preferable and more convenient as you will need only a single MSI file (though it is questionable if this would then pass validation for Vista/W7)

However - if your application is offered as either a 32-bit and 64-bit build (dependant on the client OS) it is a little different.

If you intend to offer only MSI installers – you will usually need to have two installers of your own anyway – one for x86 and another for x64, And it is academic which of our installers is used – MSM or EXE. But, if you provide an MSI with 'bootstrap' (it may be MSI + EXE, or a single EXE with embedded MSI) you will provide just one installer, And again it does not matter which of our installer options you use - but you within your MSI installer you must initiate the correct version of our driver to install for the relevant OS and processor - 32/64 bit.

Finally
> How do I (in vb) get to the return value of an IPXCPrinter method such as AddSMTP Server?

This method has no return value – the new SMTP server becomes the current SMTP server for send mail

[Bob Dukes]

John - Thanks for clarifying the different install options. Your comments were very helpful. My application currently needs to be compiled as x86 because it uses the Jet engine to control an Access data base and Microsoft's Jet OLEDB 4.0 is not 64-bit compatible. So on 64 bit systems, it runs under WOW64. I haven't had any problems on 64 bit Vista/Windows7 using the VS2008 generated .msi. There is an Access database engine 2010 redistributable on Microsoft's download site that supposedly provides an x64 oledb driver for Access, but I haven't had time to go down that road yet.

The reason I asked about accessing the return values for IPXCprinter methods was that the 3.2 Methods section in the API manual states "Return value The method returns S_OK if successful; otherwise an error code is returned". Thanks for clearing that up as well.

I'm hoping to finish my install tests for my application that has your API intgrated in the next couple of days. Will let you know the results and which of the methods you outlined I used. - Bob

[John - Tracker Supp]

Thanks Bob, good luck and let us know if you have any problems.

[Bob Dukes]

John,

I just downloaded the .msm files from the Drivers API SDK page on your web site and saved them to a temp directory. Both the x86 and x64 have .doc extensions (e.g. Driver_MSM_x86.doc). Is it just the extension is wrong and I should rename them to have the .msm extension or are these something else? -Bob

[John - Tracker Supp]

Hi Bob,

very, very odd - on one machine here its identified as .Doc - but downlaods correctly with the MSM ext - so all ok - on another its both identified and downloaded as a .doc !

Very wierd - but the file is correct and just needs the extension correcting - this is one for our web dev team.

Apologies for the confusion - we will resolve asap.

Thanks and sorry for the confusion !

[Bob Dukes]

John - Thanks for the quick reply. Will make the extension changes and start my installation testing.

[Paul - PDF-XChange]

Hi Bob,

it looks like an issue with the mime-types when files are delivered via our cloud based file delivery. We are investigating this and it will be resolved.

regards.

[Bob Dukes]

John - After having some problems with .msm files, I decided to use the redistributable for the install testing. I created a small .cmd file that the end user can use to install both my application .msi and and the redistributable and an 'uninstall' start menu shortcut that the application .msi installs. The 'uninstall' shortcut uses another small .cmd file which uninstalls both my application and the redistributable. The install .cmd file uses the /PName option to create a printer with a name I can check when ever my application is started to make sure the redistributable hasn't been inadvertently uninstalled. I've tested on both a Windows7 32 bit and a Windows7 64 bit system and it works fine.

Could you tell me what the redistributable does if the end user already has a licensed copy of your software on the system? Will it still create a printer with the /PName specified? If the end user deletes his licensed copy, what happens to the printer and files created by the redistributable? Thanks - Bob

[John - Tracker Supp]

Hi Bob,

If the driver exists already - provided a different name is specified a new printer is installed and the driver is updated for both copies.

If the user deletes from the printers list - only the specific printer deleted is removed - not any other.

BUT - if the user uninstalls one copy via the control panel options I am afraid - both are removed as they are common in this sense.

We are looking to make this different in an update so that only 1 version would be uninstalled if specified.

HTH

[John - Tracker Supp]

Also Bob,

the MSM download issue has been traced to an incorrect FTP scripting problem when transferring the files to the Rackspace Cloud enviroment - this is now corrected and in tests here works 100%

Here are the MSM module links should you wish to try again.

x86 module
https://www.pdf-xchange.com/Driver_MSM_x86.msm

x64 module
https://www.pdf-xchange.com/Driver_MSM_x64.msm

Hope this helps

[Bob Dukes]

John - Thanks for the posts re the new .msm downloads and my uninstall questions.The .msm issues I ran into during my install tests were these: I was unable to include the .msm x64 version into my install package because it's marked as x86. This is due to the my application using the MS Jet 4.0 OLEDB drivers which are 32 bit only causing me to have to compile as x86. As I mentionned earlier, I will try replacing them with Access database engine 2010 64 bit drivers when i have the time and that should take care of that. I was able to include the x86 .msm package and test it on a windows 7 32 bit system. It ran fine, but when I uninstalled my application, the automatic shutdown initiated by the .msm package got Windows 7 messages saying the shutdown was waiting for application(s) to close. I'll also pursue that issue at a later date. That does make wonder me though that if the .msm forces an uninstall during an application uninstall, isn't there a problem if the user has a licensed version of PDF-XChange he's using for other applications? - Thanks, Bob

[John - Tracker Supp]

Hi Bob,

thanks for the feedback - we will watch progressive posted here.

Further to are correct in regards the uninstall having the potential to cause issues - though it is also possible to perhaps check the registry for an end user serial number value and if this exists to not perform the driver uninstall.

Also - you could always at install time check for the existence of the driver and if it exists store a value to note this and if uninstalling call this value into play and not perform an uninstall

Just thoughts - but I am sure there are ways to pre-empt the potential for issues, other alternatives may well be worth considering ...

[Bob Dukes]

Hi John - I'm going to stick with compiling my application as x86 for now. I was planning on using the Microsoft Access 2010 database which has both 64 bit and 32 bit versions to replace the 32 bit only Jet 4.0 engine. The 2010 engine supports windows XP SP3 and higher which is what we're targeting for. Unfortunately, you can only use the 32 bit version on XP so I'd still be stuck with running a 32 bit version of my application on 64 bit XP windows. Migrating to SQL server makes no sense either since my application database requirements are small. I've wrote some vbscripts which install my application on both 32 bit and 64 windows using an msi file for my application and your PDF-XChange redistributable. That all works well, but I wanted to go back and try using just an msi file which has your x86 masm module included. What I wasn't sure of is whether it will install correctly on a 64 bit system. I'm hoping it will since my application msi package is tagged as 32 bit. I'm going to try it in the next couple of days, but would appreciate it if you could get back to me if you know it's not feasible. - thanks, Bob

[John - Tracker Supp]

Hi Bob,

If I understand correctly - you want to use a single 'x86' .msm file in a single x86 MSI installer to install the driver on both 32 and 64 bit machines ... ?

If so, this is not possible - we currently use an x86 MSI installer and an x64 MSI installer in either circumstance as appropriate - however we are told in principle a single MSI installer can be used with 2 differing .MSM files (x86 and x64) as appropriate - but its not so easy and there are some complex rules to follow (pls don't ask me just yet - because I don't know )

We are looking into this ourselves for a future release so we can provide a single set (1 x MSI + 2 x MSM) for the dual install needs of x86/x64 systems and when further down the road we would be happy to share accordingly ..

HTH