I need help - I can help - DLL Edition Getting Started with Delphi 7

Print Page | Close Window

DLL Edition Getting Started with Delphi 7

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=3483
Printed Date: 02 May 25 at 4:09AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: DLL Edition Getting Started with Delphi 7

Posted By: HNRSoftware
Subject: DLL Edition Getting Started with Delphi 7
Date Posted: 09 Jul 17 at 1:52PM

I feel like an idiot this morning. I've been using QuickPDF dcu edition since version 7 (now on 13.12) with minimal problems. My primary issue has just been that I don't like 4 megabyte exe files for "hello world" level applications, and I would think that using the DLL edition would fix that.

My problem is with "Getting Started with DLL Edition" in the Developer Guide. There is only a single page, and it is just code fragments in some non-Delphi language. I can't see the entire code structure that the DLL edition is assuming. The sample code on the website all appears to be dcu edition as well.

"DPLCreateLibrary" and "DPLReleaseLibrary" appear to be calls into the dll itself, so it is totally unclear to me in what order things have to be done. It is not even clear to me where the DLL itself has to be located for the program to find it at run time.

Is there a simple reasonably complete delphi example available? Even something as simple as a routine that loaded the dll, unlocked it, got a page count of a pdf file then released the dll would tell me what I think I need to know.

Thanks - Howard Richoux

Replies:

Posted By: tfrost
Date Posted: 10 Jul 17 at 11:34AM

Look in the install folder Debenu\PDF Library 13\DLL\Import\Delphi. Here you will find the PAS file which gives you access to the DLL from Delphi. You must include this in each unit to get access to the function declarations in its interface section. And of course the DLL must be located on the path for applications to find it at run time.

I also considered using the DLL to reduce the bloat in every program which uses the Debenu functions. However it is much harder to use from Delphi than the DCUs and I eventually abandoned the idea. The problem for us was that because the DLL is generic for lots of languages, you cannot use functions involving streams (or have to load from PAnsiChar buffer instead), and you can only pass PChar values, not Delphi strings. So our applications would have needed a large number of (admittedly small) changes, which made the whole idea impractical.

Posted By: HNRSoftware
Date Posted: 10 Jul 17 at 1:12PM

Thanks for the info - that may be why I didn't go that way a few years ago. I had found the dll interface unit already, but it is the using (/meaning) of "DPLCreateLibrary" that has me puzzled. The normal dcu library usage has me creating a TQuickPDF object, then doing the unlock, some basic units settings, some work and then freeing the object. It is not even clear to me whether I can tell the program to go look for the dll in a specific place or whether it MUST reside next to the exe (I recall something about a path of alternative locations, but don't think I liked any of the choices). My programming structure is to make lots of little projects to do things rather than one big program with lots of features. I don't like to break existing code to try new things. I would prefer to place all my DLLs in a single folder somewhere of my choosing so that is is easy to move between desktop(s) and laptop(s). My programs do not get "installed".

I have never been happy with the contortions necessary to use pchar, so usually I create another layer of calls that hide this from me. This also means that I don't think about the stdcall stuff much and don't have a good feeling for what is going on underneath the hood.

Thanks - Howard

Posted By: tfrost
Date Posted: 10 Jul 17 at 3:33PM

You can see from the source in the import folder that DPLCreateLibrary gets called from the class constructor and initialises the FInstanceID which is used internally by all the class methods. So I don't think you need bother with it once you have created the TDebenuPDFLibraryDLL1312 class (which is the equivalent of the TQuickPDF object you create now).

The path to the DLL is set in the parameter to the class constructor, so you can put it anywhere you like and specify the path to load it. If you only include the DLL filename, Windows will find it using the standard rules: first in the same folder as the EXE, then in the Windows path.

Finally, you do not need to bother with stdcall when you call the functions of the class: these functions use the stdcall only when they access the DLL, but you should never need to access the DLL entry-points directly.