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

http://www.debenu.com/wp-content/uploads/Foxit_Quick_PDF_Library_15_DLL_GettingStarted.pdf" rel="nofollow - https://www.debenu.com/wp-content/uploads/Foxit_Quick_PDF_Library_15_DLL_GettingStarted.pdf

I once considered using the DLL interface in the past but quickly rejected it (for Delphi) because of the difficulty or impossibility of handling string and stream parameters.  I guess that is why there is little mention of using it in a Delphi context.  And by the way it would not make sense to create and free the library for every function call, as in your test, because that would force a load of the DLL each time.

@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.

I agree with the initialization/finalization - just wondering where it SHOULD be put.

My point on the dll loading in create it that it bears no resemblance to the documentation on how to use the dll edition.  Obviously it is good that it does it.

The benefit of multiple create/free is that pdf is not central to most of my applications so simple pdf operations like counting pages in a pdf file might be added/removed and I want code that executes reliably, so I minimize the assumptions a program makes about its environment.  If I want to count the pages in 1 file, I can accept the dll loading overhead of a fraction of a second.  If I want to count pages in 1000 files, I use a different function that brackets the whole job in create/free, so the overhead is one load/free for that too.

Mostly I have not been able to detect the load/free overhead, so it can't be much.