Gnostice eDocEngine does not work with C++ Builder XE3

Update, February 25, 2014:  I just tested again, using a fresh install of RAD Studio XE5 Update 2, into which no other components had been installed.  I downloaded the trial version of eDocEngine from today, and ran the install into RAD Studio XE5.  I did not run any of the interface installers.  I then created a C++ Builder VCL project with one form, and dropped a TgtPDFEngine component on the form.  I then dropped a TButton, and in the click handler, I added


The program compiles, links, and runs, but when the button is clicked, I get a PDF Setup dialog.  When I click OK without making any changes in the dialog, I get an error:  “Project Project1.exe raised exception class $C0000008E with message ‘floating point divide by zero at 0x006d5a5a’.”.  Thus, as of this point, eDocEngine remains unusable in C++ Builder XE5 Update 2.  Gnostice support says they have a workaround, but it requires turning off Runtime Packages, which, with my application, prevents it from running.


I have been using Gnostice’s pdf generation products for a while now, using C++ Builder XE.  Recently, I wanted to move to the current version of C++ Builder, version XE3.  I installed a new version of Windows 7 under Parallels on my Mac, and installed RAD Studio XE3, and the various packages I use, keeping snapshots along the way.  Ultimately, I built my application, and with a few manageable changes, it compiled and ran.  However, when I created the form that contained the PDF Engine component from eDocEngine and built the project, the resulting program crashes with a “floating point divide by zero” error when the form is created.

That was using eDocEngine 3, the most current version available when I was migrating, in January 2013.  I submitted a support request to Gnostice on Jan 18, 2013, about multiple install problems (see below), and a separate support request on Jan 22, 2013 with the show-stopper “floating point divide by zero” error, and although they have sent a few confirmations, and stated that they can reproduce the problem, they have not found a solution, and eDocEngine 3 still does not work with C++ Builder XE3.

In early February 2013, Gnostice released eDocEngine version 4, and so I tried installing that.  The main installation program worked (although the importers still fail).  Unfortunately, a C++ Builder XE3 project onto which a TgtPDFEngine component is dropped will not compile (the first error is an #include of “NtDef.h”, which does not exist in my system – it appears to be included by a JEDI file).  I managed to get a test program to compile by removing that #include, and substituting fragments of NtDef.h and other files for the missing include file, and ultimately got my simple test program (a TgtPDFEngine component on an empty form, with no code whatsoever) to compile, build, and start, but the same “floating point divide by zero” error occurs on startup.  Thus the same problem appears to occur with eDocEngine 4.  I submitted a support request regarding that on Feb 9, 2013.

I did some additional testing on eDocEngine 3 under XE3, which I reported here: .  It appears that the problem is that, in XE3, the components are not being correctly initialized when linked for C++, although they are for Delphi.  One of the variables that should be initialized, thus, is not, and is still zero.  When it is used, the divide by zero error occurs.

My environment for testing is a brand new version of Windows 7, with a brand new installed and registered RAD Studio XE3.  Because I am using a virtual machine (Parallels on a Mac), I can use snapshots to make sure that there is no other software or component installed, so I know that the problem is with eDocEngine.  All that is required to produce the problem is dropping a TgtPDFEngine component on the form of a C++ project.  No code or other components are required.  If a TgtPDFEngine component is dropped on the form of a Delphi XE3 project, the program compiles and runs.  I thought I might try controlling the TgtPDFEngine component through a Delphi form, but no luck: if you create a C++ project, and then add a Delphi form and drop the TgtPDFEngine component on the Delphi form, the same divide by zero error occurs on program startup.

At this point, it has been well over a month since I brought this to Gnostice’s attention, with no resolution or indication that they have any clue as to how to fix it.  I cannot do any development with my new XE3 environment until they do, or alternatively I find another PDF library to use instead.  The other, non-PDF components do not seem to have this problem.  If you have any suggestions, please make a comment below.

Here is the text of my original support request, noting multiple problems with the eDocEngine installation routines under C++ Builder XE3 — I sent this request to them on Jan 18, with no substantive response as of yet (Feb 28, 2013)


I just installed the newest version of the three VCL products, and had some difficulties accessing them using C++

The eDocEngine VCL installation completed without issue until I came to the exporters.  I wanted to use the FastReports, DevExpress, HTMLViewer, and TRichView / ScaleRichView exporters.  All four that can be installed using your exporter generator failed immediately, and the error log that the generator said would be created was not created (and no file with that filename was created anywhere within my system)

So, THE FIRST PROBLEM is that the exporter generator fails completely, and THE SECOND PROBLEM is that the exporter generator does not create any log file.

I do have all five underlying components installed into my RAD Studio XE3 through Delphi, but with C++ files created, so that I can use them in C++ as well — I initially did that for Gnostice, since Gnostice could not use the components when installed directly into C++ (see my blog post for details: ).  The exception is DevExpress, which just has a single installation program that installs the components into both personalities, without any options in the current version, so I have DevExpress installed using their installation program.  I am using the most current version of DevExpress, v2012 vol 2.2 .

I manually generated all five exporters per your instructions, modifying the project files to generate all C++ Files, including package libs (as I have for all of the components I have discussed, so I can use them in C++ — see for more details on how I had generated HTMLViewer.)  Of note, your installation packages do not have an XE3 version for the HTMLViewer exporter, so I used a modified version of your XE2 version of the exporter project, so THE THIRD PROBLEM is that you do not include a project file for the HTMLViewer exporter under XE3.

All five of the exporters installed, and all but the DevExpress one can be dropped on a C++ application and the application will compile and run.  All five can be dropped in a Delphi application and the application will compile and run.

So, THE FOURTH PROBLEM is that the DevExpress exporter component causes a compile error when merely dropped on an empty form by itself.  The exact error is “Declaration terminated incorrectly”, encountered when parsing gtXPressPrntIntf.hpp after having parsed vcl.h, System.Classes.hpp, Vcl.Controls.hpp, Vcl.StdCtrls.hpp, Vcl.Forms.hpp, gtClasses3.hpp, and gtXportIntf.hpp .  The error occurs on line 282 of System.ZLib.hpp, while reading the extern DELPHI_PACKAGE char *ZLIB_VERSION; line

Other problems encountered in the exporter generator process: THE FIFTH PROBLEM is that many of the exporters have the old names for the units in the .pas files, including FastReport, which uses Graphics (which has been renamed to Vcl.Graphics), Controls, StdCtrls, and Dialogs .  By renaming those, I was able to get that exporter to compile.  The other exporters had similar problems, and required the source .pas files to be changed to get them to compile in XE3.

Then, I installed PDFToolkit VCL.  The installation went without problem, and I can drop the TgtPDFViewer on a C++ form and get the application to compile and run.  Same for TgtPDFDocument, and TgtPDFPrinter.  However, if I drop a TgtOutlineViewer on the form I get a link error: Unable to open file GTPDFOUTLINEVIEWER.OBJ .  If I drop a TgtPDFSearchPanel, I get the link error Unable to open file ‘GTPDFSEARCHPANEL.OBJ’ .

So, THE SIXTH PROBLEM is that I cannot use either of those two components in a C++ project without generating a link error.  Often, that error will occur if the .lib file containing those units is not Added to the project.  I can certainly do that manually, if you tell me which .lib library file contains those units.  Note that all five components can be added to a Delphi project without difficulty.

Finally, I installed the XtremePDFConverter.  Again, the installation went without incident.  However, when I drop a TgtPDFConverter component on a C++ form and try to build, I get a “Find Static Library” dialog, “Unable to find static library gtRTFBaseD17.lib”  .  That .lib file does not exist on my system, although gtRTFBaseD17.bpl, .dcp, .dpk, .dproj, .rc, and .res do.

So, THE SEVENTH PROBLEM is that I cannot use the XtremePDFConverter in a C++ project.  It works in a Delphi project.

Please advise how I can address these problems, specifically where I can get the missing .lib files for PDFToolkit and XtremePDFConverter (I could probably recompile the packages to create them myself, if that is your recommendation), and how I can get the DevExpress Print Exporter to work (I don’t have a clue where to start with that one).

Note that I have my system in a virtual machine, so I can easily switch between system snapshots if there are installations you would like me to test.


One thought on “Gnostice eDocEngine does not work with C++ Builder XE3

  1. Up until recently I was using C++Builder6 as my compiler utilizing Gnostice edocEngine for exporting to .pdf, ,html. xls in a number of programs. My problem first occurred when the exported .xls file would not load into Excel 2010 or Excel 2013 which one of my customers was using. Gnostice advised that the xls format used an internal Excel 97 format which was not compatible with the newer versions of Excel. I thought that strange seeing that I could read older .xls sheets into Excel 2010 on my computer. As it turns out it was an internal coding problem, in versions2 through version 3. They completely rewrote the code for Version 4.
    My newer problem now was that ver 4 did not support CB6. Initially I was taken back with the hurdle of converting to unicode so I deferred upgrading and decided to use a the TAdvSpreadSheet component from TMS to create the .xlsx output. Later in the year after reading all the issues for converting to Unicode I decided to take the plunge and purchased C++BuilderXE2 and then upgraded to eDocEngine ver 4 with intention of migrating all my projects to the new compiler.
    Well that is when my major headache started (this is still 2012). First off I could not get eDocPro ver4 to install into XE2. After several back and forth messages with Gnostice they finally provided me a supposedly working installation of ver4; however the RaveReports Interface installer failed and all my reporting was done through code based Rave. They sent me 3 temporary fixes which did not work either so they wanted to connect to my computer but we could not get together on a time frame seeing that they are about 12 hour ahead of Pacific Time. Then I put everything off because it was the end of the year. I started back up in Feb 2013 with no success installing and getting a good compile/build in XE2, having similar problems that you described.
    Later I decide to pop for RAD studio with backward versions and began installing RAD 2007, 2009, 2010 & XE. Believe it or not, I still can’t get eDocEngine to do a clean build in either of the earlier versions nor XE2. Just the other day 3/6/14 they gave me version which they said will work with RAD2007-wrong! It installed along with RaveInterface (finally) but it doesn’t clean build with runtime packages=false. Turning runtime packages back on, it builds ok but I haven’t tried building a small project to check it out. They tell me that I need two .LIB files which I downloaded but with RTL packages set to false, I get about 2 dozen Unresolved external errors so I gave it back to them for another try at fixing it. Like you said, they don’t appear to know where to fix the problems.

Leave a Reply to ed rokosz Cancel reply

Your email address will not be published. Required fields are marked *