TTMSFMXPDFLib Access Violation at call to NewPage() Method

I am attempting to use the PDF library to export documents from my program, but every time the NewPage() method is called, the program throws an access violation. I attempted to explore the issue using the TMS Memo control and the Memo PDF IO object to export the memo. It throws an access violation as well, which I am willing to bet occurs at the NewPage() method call. I can provide the entire project for the Memo issue, along with the executable I have created, which I have verified throws the access violation on other machines.


#include <fmx.h>
#pragma hdrstop

#include "PDF_main.h"
#pragma package(smart_init)
#pragma link "FMX.TMSBaseControl"
#pragma link "FMX.TMSCustomComponent"
#pragma link "FMX.TMSMemo"
#pragma link "FMX.TMSMemoPDFIO"
#pragma link "FMX.TMSPDFIO"
#pragma resource "*.fmx"
TForm1 Form1;
__fastcall TForm1::TForm1(TComponent
: TForm(Owner)
void __fastcall TForm1::Button1Click(TObject *Sender)
if (SaveDialog1->Execute()) {

Please provide a test application. Does this happen in an empty memo, or does it have a certain number of pages?

PDF.cpp (862 Bytes)
PDF_main.cpp (914 Bytes)
PDF_main.h (1.2 KB)
PDFPCH1.h (63 Bytes)
I just typed one line into the memo.
PDF.cpp (862 Bytes)
PDF_main.cpp (914 Bytes)
PDF_main.h (1.2 KB)
PDFPCH1.h (63 Bytes)

Is there a way to provide the executable image? It is linked with the debugger so you may be able to find the cause of the exception by remotely attaching to it.

No, we don't open executables here

I understand.

The FMX form file is missing, please ZIP the whole project, excluding the exe and attach it here. (10.2 KB)

We are not able to reproduce this here. Are you using the latest version? Are you able to reproduce this in Win32 target?

I am using the latest version. I am unable to create a Win32 target as every attempt ends in an ilink32 error:

[ilink32 Error] Error: 'D:\USERS...\APPDATA\LOCAL\TMSSOFTWARE\REGISTERED\TMS FMX UI PACK\TMSFMXPACKPKGDXE14.BPI' contains invalid OMF record, type 0x2f

I was concerned about your inability to recreate the problem. It is so pervasive, you would not have shipped the library had you known it was in this state. The only way we will get to the bottom of this is for you to accept the executable I have created. I understand why you are opposed to this, but I have an isolation laptop I use in similar circumstances.

As things stand, the entire PDF offering in your package is useless to me, but I really do need it.

This is the versioning information for my RAD Studio installation.

We have tested this here with C++Builder 11 Update 2 as well. Attached is the sample with executable inside. Due to company policy we cannot open executables here unfortunately. Is the content inside the memo crucial to reproduce the issue? (154.5 KB)

It did not matter what I put into the memo.

What I am really wanting to do is draw my own document using TMSFMXPDFLib directly. When I add the following code to the Button1Click method BEFORE the attempt to export the memo, I get the same exact exception in the same exact location as the memo export exception:


p_pdf = new TTMSFMXPDFLib();

p_pdf->PageSize = psLetter;

Hmm could be related to the DLL to load fonts (FontSub.dll). Can you try turning off runtime packages? Also, if you have access to Delphi, are you able to reproduce the access violation there? It could be possible that we are testing with a newer version here specifically related to 64 bit types inside the PDF lib. We'll see if we can release an update of TMS FMX UI Pack.

I do have access to Delphi and I thought about doing that very test this morning. As for turning off runtime packages, the actual application I am building is completely statically linked, so no runtime package loading issues in that application. However, I will try it in the test app.

We are currently building a new version as well, so we are both testing with the exact same version. The previous version was from July 2022. It should be available in a couple of hours as version v3.7.8.4

Thank you! I have always had good experiences working with TMS.