You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2015-10-11 01:28:58
- jkelley
- Member
- Registered: 2015-10-11
- Posts: 6
C++Builder support
I've been looking for a good, free PDF library that's easy to integrate into our C++Builder projects. From my brief time playing with it, PDF Engine is a good, free PDF library that's... kind of easy to integrate into our C++Builder projects.
I'm sure that C++Builder support isn't a primary goal with this library, but would you be open to code changes to make it work?
Here are the problem areas:
Macro conflicts: Some constants in SynPdf.pas conflict with macros in Microsoft's wingdi.h. Fixing these is easy; just exclude them from the auto-generated SynPdf.hpp:
{$NODEFINE MWT_IDENTITY}
{$NODEFINE MWT_LEFTMULTIPLY}
{$NODEFINE MWT_RIGHTMULTIPLY}TSynValidateText: C++Builder apparently doesn't support using array elements as properties. This prevents TSynValidateText and TSynValidatePassWord from working. I can think of two workarounds:
Simply exclude them from the .hpp files (using {$NODEFINE}), so that they won't be accessible from C++ code but the rest of the library will work.
Make a bunch of setter and getter functions (GetMinLength, SetMaxLength, etc.) so that the properties can be implemented in terms of them and they can be implemented in terms of the fProps array.
At this point, our needs are pretty simple - we just want to create a PDF file, write to it with the VCLCanvas, then save it. So I'm tempted to use {$NODEFINE}, to avoid adding complexity to the code that isn't currently needed.
Script... records and functions: Delphi apparently can't export variant records in a format that C++Builder can use. This affects TScriptState, TScriptAnalysis, TScriptItem, and TScriptVisAttr. As I understand it, these records and the functions that use them exist only in SynPdf.pas to provide Delphi access to usp10.dll. C++ code can already access usp10.dll by including usp10.c, so it seems best to {$NODEFINE} all of these records and all of the Script... functions.
TZipWrite: The last problem is in TZipWrite.CreateFrom. Because Delphi constructors are exported to .hpp as standard C++ constructors, and because standard C++ constructor overloads are all named after the class and can only be distinguished by their parameter list, having two Delphi constructors that have identical parameter lists creates problems. The docwiki has more details. The workaround that they suggest there - adding a default-value "dummy" parameter to distinguish the two - is ugly, but it's simple and works and doesn't affect callers.
Are you willing to add these workarounds to the PDF Engine? If so, I can submit a full patch (or PR on GitHub, or whatever you prefer).
Offline
#3 2015-10-15 02:23:43
- jkelley
- Member
- Registered: 2015-10-11
- Posts: 6
Re: C++Builder support
My initial C++Builder work was only for the latest release version. I see now that the development version uses "object" for TTimeZoneData and TTimeZoneValue, and that's also causing problems for C++Builder.
Pardon my ignorance, but what's the difference between a record and an object in Delphi? It looks like changing TTimeZoneData and TTimeZoneValue to record will make C++Builder happy, but are there any disadvantages to doing so? (From looking around online, all I can tell is that "object" is needed for class-like behavior in pre-Delphi 2006. Are there other differences?)
Offline
#5 2015-10-22 02:38:46
- jkelley
- Member
- Registered: 2015-10-11
- Posts: 6
Re: C++Builder support
I submitted a PR to https://github.com/synopse/SynPDF/pull/5. Thank you.
Offline
#6 2015-10-22 06:46:55
Re: C++Builder support
Your patch has been introduced to the trunk.
See http://synopse.info/fossil/info/782c634febe5
and http://synopse.info/fossil/info/cfb3359e21
Thanks a lot for sharing!
Offline
Pages: 1