On a handful of workstations, we are finding that the call to DriverInit during our installation procedure hangs - sometimes for as long as 30 or 40 minutes.
Eventually, it does go through, and everything works after that - but, obviously, the huge delay is a perception problem with the end user.
Any ideas on what might be causing this?
Thanks!
- Kevin
Install of printer using DriverInit is very, very slow
-
trumpetinc
- Posts: 60
- Joined: Mon Jul 28 2003
Hello,
A call to DriverInit will take 30 to 40 mins? This is impossible ! ! !
Are you having the PDF Printer installed on your system using Install.exe before calling DriverInit()? DriverInit will not install a printer, it will search for the specified printer and if available it will attach to it.
The functions that will install a printer is called PDFDriverInit(), it will not take 30 mins and not even 1 min to execute, it will look for a given printer and if not found it will try to install it.
Please give more details about your installation procedure so we can check what could be going wrong.
Hope this hepls.
A call to DriverInit will take 30 to 40 mins? This is impossible ! ! !
Are you having the PDF Printer installed on your system using Install.exe before calling DriverInit()? DriverInit will not install a printer, it will search for the specified printer and if available it will attach to it.
The functions that will install a printer is called PDFDriverInit(), it will not take 30 mins and not even 1 min to execute, it will look for a given printer and if not found it will try to install it.
Please give more details about your installation procedure so we can check what could be going wrong.
Hope this hepls.
-
trumpetinc
- Posts: 60
- Joined: Mon Jul 28 2003
Driver install reply
Woops - sorry - I mis-read my source code when I wrote my original message.
You are correct, we are installing using a call to PDFDriverInit.
Here is the exact procedure we use (in pseduo code - we actually use C++) for install:
- Loadlibrary cdintf210.dll from our application's directory (we renamed cdintf210.dll before we package it into our installer)
- converter = PDFDriverInit("Printer name") // set up printer
- if converter == null, try copying the wbem\\framedyn.dll into the system32 folder, and call PDFDriverInit again. // this fixes a problem where the driver install fails on workstations with incorrect path configuration
- if converter still == null, get last error and present warning to user
- converter = DriverInit("Printer name") // make printer install persistent
- if converter == null, get last error and present warning to user
- Unload cdintf.dll library from our application's directory
- Compare version of cdintf210.dll in windows system directory to cdintf210.dll in application directory. If the file in the application directoy is newer, copy the application cdintf210.dll into the system directory.
At this point, I am not certain that the delay is happening in PDFDriverInit or DriverInit (although I suspect it is in PDFDriverInit). I will try to gain access to the workstation again and run some debugging code to find out for sure.
From looking at the above code, I suppose that I could copy the cdintf210.dll file into the system directory before I call PDFDriverInit() - but I can't imagine that would make any difference whatsoever. I think we set it up this way because of instructions in the cdintf guide that shipped with the driver - but we could have mis-interpreted that.
Please let me know what you think!
- Kevin
You are correct, we are installing using a call to PDFDriverInit.
Here is the exact procedure we use (in pseduo code - we actually use C++) for install:
- Loadlibrary cdintf210.dll from our application's directory (we renamed cdintf210.dll before we package it into our installer)
- converter = PDFDriverInit("Printer name") // set up printer
- if converter == null, try copying the wbem\\framedyn.dll into the system32 folder, and call PDFDriverInit again. // this fixes a problem where the driver install fails on workstations with incorrect path configuration
- if converter still == null, get last error and present warning to user
- converter = DriverInit("Printer name") // make printer install persistent
- if converter == null, get last error and present warning to user
- Unload cdintf.dll library from our application's directory
- Compare version of cdintf210.dll in windows system directory to cdintf210.dll in application directory. If the file in the application directoy is newer, copy the application cdintf210.dll into the system directory.
At this point, I am not certain that the delay is happening in PDFDriverInit or DriverInit (although I suspect it is in PDFDriverInit). I will try to gain access to the workstation again and run some debugging code to find out for sure.
From looking at the above code, I suppose that I could copy the cdintf210.dll file into the system directory before I call PDFDriverInit() - but I can't imagine that would make any difference whatsoever. I think we set it up this way because of instructions in the cdintf guide that shipped with the driver - but we could have mis-interpreted that.
Please let me know what you think!
- Kevin
Hello,
2.10 version is not our most recent version, please check that you are using 2.10i-9 that is the latest 2.10 release or you can check our latest version 2.50 if you want.
Concerning your installation, why you don't install the printer using Install.exe and than in your application just call DriverInit and omit the call to PDFDriverInit?
Please try to install the printer on this workstation using Install.exe and then run your code, will this run faster?
2.10 version is not our most recent version, please check that you are using 2.10i-9 that is the latest 2.10 release or you can check our latest version 2.50 if you want.
Concerning your installation, why you don't install the printer using Install.exe and than in your application just call DriverInit and omit the call to PDFDriverInit?
Please try to install the printer on this workstation using Install.exe and then run your code, will this run faster?
-
trumpetinc
- Posts: 60
- Joined: Mon Jul 28 2003
Followup...
The primary reason I don't use install.exe is that there is no way to know whether it succeeds or not in my installer, so I can't provide the user with a meaningful error message.
I will try installing using install.exe to see what happens with the speed.
If there is a difference, then I am quite interested in what you are doing in install.exe that is special - I'd assume you all are just making the same calls to cdintf210.dll.
Thanks again - I'll let you know what happens with the test,
- K
I will try installing using install.exe to see what happens with the speed.
If there is a difference, then I am quite interested in what you are doing in install.exe that is special - I'd assume you all are just making the same calls to cdintf210.dll.
Thanks again - I'll let you know what happens with the test,
- K
Joan wrote:Hello,
2.10 version is not our most recent version, please check that you are using 2.10i-9 that is the latest 2.10 release or you can check our latest version 2.50 if you want.
Concerning your installation, why you don't install the printer using Install.exe and than in your application just call DriverInit and omit the call to PDFDriverInit?
Please try to install the printer on this workstation using Install.exe and then run your code, will this run faster?