Dynamically using cdintf.dll

[jstahl]

We are using successfully using the developer edition version 3.02 to print PDF files from our app via the C/C++ API. However, with some clients it is not possible to install a printer driver. For this, we tried to dynamically load the cdintf300.dll and call its functions. This is necessary because the windows app loader aborts the loading process if the cdintf.dll is not available if the library is statically bound using its LIB file.

LoadLibrary(...), GetProcAddress(...) are working well, aswell we can successfully call the DLLs functions. However, EnablePrinter doesn't work. The function call itself works, but starting the printjob rightafter the EnablePrinter call leads to a Printer not activated -30 error. The function sequence with static bound library works well.

Any clues?

Thanks,
Jojakim Stahl
demig Prozessautomatisierung GmbH

[lp]

That's quite strange.
I'm currently using such a dynamic method to invoke the cdintf.dll functions and have no troubles doing it through the DLL interface in the very same way you did.
I've tried this on v2.10, v2.50f, v3.01a and v3.02 also..
You can check:
a) timings: be sure you don't wait too much after enabling the printer, otherwise it would not work (that's what I get when stepping in during debug)
b) licensee and licence string: I'm pretty sure you cut-n-pasted them, but it's always better to double check
c) also ensure you are using the correct one, not one for a previous version (but probably you are already ok, since you said the static approach does work..). As a matter of fact license codes from newer versions still work on old versions of the driver, but the opposite isn't true..

HTH
have a nice day
Luke

[Joan]

Hello Jsthal,

At the time you are calling EnablePrinter() do you have an Amyuni PDF Printer installed on the system or not?

If not than EnablePrinter will not work, which printer will it enable?

Thanks

[jstahl]

Hello,
I don't believe this to be a timing problem.
I'm doing the exact same sequence of function calls statically and dynamically. (without debugger). The static version works, the dynamic not.

Can this be a threading problem? I'm calling from a diffrent thread than the UI is running in. I read somewhere that dlls using __declspec(thread) are not usable via LoadLibrary. Why?? I do not know.

If I find some time, I will try to build a wrapper DLL that binds to cdintf.dll statically, and then loading the wrapper dynamically.

Thanks so far.

Jojakim

[Joan]

Hello,

If you are in multithreading environment you need to use the Locking mechanism of CDIntf. You will find more information about it in the Developers' mnual "Common Driver Interace 300.dll" that you received with the product.

Unfortunately i still didn't get if the problem is about installing the PDF Printer or printing to it. You below email confuses me a little bit.

[jstahl]

Dear Joan,
to clarify:

- The system where I am testing has the printer pre-installed. Therefore I do not try to install the printer again.
- I am using Lock(hPrinter, szLockName)
- When statically linked, all works well
- When dynamically linked (calling function pointers that have been setup using GetProcAddress) the 'printer not activated' error arises.
- All I change between statically linked and dynamically linked is the name of the calls
i.e. Lock() into fnLock(), where fnLock is a function pointer setup by GetProcAddress
- The position and sequence of the calls is not changed.
- Multithreading, in my case, doesn't meen printing from many threads in parallel. I start only one print at a time, but not within the GUI thread, but in a background thread, while the GUI displays progress.

Thanks for your support, Joan.

Jojakim Stahl

[jstahl]

Hello, I'm back to this problem again.

I created a DLL now that binds to cdintf.dll at link time (statically). This DLL exports a couple of own functions for Initializing the PDF printer, creating a device context etc.). From my program I load this DLL dynamically now, getting the address of the my functions with GetProcAddress. However, the very same problem as described earlier arises: Printer not activated, error code -30. The strings passed to EnablePrinter function are definitively the same.

My conclusion: There must be a problem when the cdintf300.dll gets loaded later, either directly or indirectly. It works only when it is loaded at program start time together with the exe.

Joan, any hints?

Thanx, Joja

[jstahl]

Hello,
After some reading of MSDN documentation on processes, threads, load library etc. I found the following:

At the time you call LoadLibrary, windows calls the DllMain function of the loaded library with DLL_PROCESS_ATTACH. But DllMain is not called with DLL_THREAD_ATTACH for any other already created thread in the process. Only if you create a thread after LoadLibrary, the DLLs DllMain is called for this thread.

This must be the problem in my case: I moved the call to LoadLibrary to my programs main() function. That calls it when just the initial thread of the process is running. Then it works...

cdintf.dll seems to have a problem if it's used by a thread that has not gone through its DllMain.
See http://msdn.microsoft.com/en-us/library ... S.85).aspx and http://msdn.microsoft.com/en-us/library ... S.85).aspx.

Joja