Using the DLL edition with Delphi

I've been using the Delphi edition since version 7, and just decided to see what the DLL edition looks and acts like.  I was surprised at how little mention there is of the DLL edition in the documentation, and, of what I found, virtually nothing makes sense (to me).

I am using the DLL edition to get a pdf file page count as a test.

After a bit of trial and error, this code works (but it looks nothing like the Delphi example code provided in the documentation).

I placed the dll here: C:\Delphi7\QuickPDF16DLL\DebenuPDFLibraryDLL1611.dll along with the interface pas unit, and added that folder to my library search path

My test program needed to add "DebenuPDFLibraryDLL1611" to the uses statement

const cbDLL16filename00 = 'C:\Delphi7\QuickPDF16DLL\DebenuPDFLibraryDLL1611.dll';

                        // this is where I put it
var QPDF_LicenseKey00   : string = cbMyKey16;   

                        // MUST be set by calling program for anything to work

Function QPDF_GetPageCount00(PDFfn : ansistring) : integer;      
var QP : TDebenuPDFLibraryDLL1611;
var FH : integer;
     begin
     result := 0;
     if FileExists(PDFfn) then
          begin
          QP := TDebenuPDFLibraryDLL1611.Create(cbDLL16filename00);
          try
             if (QP.UnlockKey(QPDF_LicenseKey00) = 1) then
                  begin
                  fh := QP.DAOpenFileReadOnly(PDFfn,'');
                  result := QP.DAGetPageCount(fh);
                  QP.DACloseFile(fh);
                  end;
          finally
             QP.Free;
             end; // of try
          end;
     end;

//---------------------------------------------------------------------------------------

This code performed as expected, and it wound up very close to my VCL code to do the same job.  Aside from the trial-and-error aspect, it was surprisingly easy.

The library load/unload appears to be hidden deeper in the code, since I didn't have to do it myself. I assume the internal code is loading and unloading the dll sensibly.

Howard

@tfrost - I agree with you totally, but that is actually precisely my point.  My example does not do any explicit load/unload of the dll at all.  It is being done invisibly in the create/free code, without a word mentioned about this in the documentation.  The separate getting started "manual" is just the same couple of pages as in the developers guide.  What I would hope to see in the guide is some performance-related discussion - like - does this really load/unload the library each time? or does it do something else?  Am I supposed to "load" the library at the start of the program, "unload" it at the end, and the create/frees would be able to see that the library is already loaded?  Should I stick that in unit initialization/finalization code? ...

And, yes, the stream part is critical, BUT, the tradeoff is 4Mb of exe file size (the footprint for simply "using" the QuickPDF non-dll edition).  I will add a separate question for how-the-heck do use "DARenderPageToDC".  My gut says that this should be able to render to a bitmap, but my first couple of tries at calling it crashed horribly.  My current work-around is to render a page to jpg file and load the file.

Even if you accept that you only need to initialize (and therefore load) the DLL once at the start of your application, I would never call a DLL load from an initialization section, or a Free from a Finalization. The Windows program loader is not re-entrant and you never know what the VCL is going to do in this area.

I am not concerned with the 'program exe size' issues you mention because our PDF and image processing functions are in our own DLL.  It allows our code to be simple Delphi, and reduces the installer size for the all the programs that call it.  And surely there cannot be much difference in process image size between native Delphi and DLL.