Invalid floating point operation - in Delphi

A forum for questions or concerns related to the PDF-XChange Core API SDK

Moderators: TrackerSupp-Daniel, Tracker Support, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Tracker Supp-Stefan

Forum rules
DO NOT post your license/serial key, or your activation code - these forums, and all posts within, are public and we will be forced to immediately deactivate your license.

When experiencing some errors, use the IAUX_Inst::FormatHRESULT method to see their description and include it in your post along with the error code.
Post Reply
GeoffW
User
Posts: 19
Joined: Mon Jul 23, 2018 10:01 am

Invalid floating point operation - in Delphi

Post by GeoffW »

Core API SDK v7.0 build 326. Delphi v10.2, 32bit build, under a Windows 10 x64 VM.

This has been reported before under various guises in the last couple of years.

Code: Select all

var
  idoc: IPXC_Document;
begin
  // lots of work with idoc and then
  idoc.WriteToFile(PChar(filename), nil, 0);
end;
In evaluation mode this all works without complaint. Install a serial number and you get a "Invalid floating point operation" exception when you hit the WriteToFile call.

The work-around in modern Delphi versions is something like this:

Code: Select all

var
  idoc: IPXC_Document;
  exceptionMask: TFPUExceptionMask; // bug in PDFX
begin
  // lots of work with idoc and then
  exceptionMask := GetExceptionMask;
  SetExceptionMask(exceptionMask + [exZeroDivide, exInvalidOp]); // add System.Math to uses
  try
    idoc.WriteToFile(PChar(filename), nil, 0);
  finally
    SetExceptionMask(exceptionMask);
  end;
end;
Search this forum for other/older fudges, but keep in mind that those using "Set8087CW( $027F );" are generally presented as one-off calls, but a try/finally wrap around, as above, may be wiser if your application uses floating point math (most do): Delphi programmers are used to being told when their math gives unexpected results, and globally turning off such notifications is a dubious recommendation.

Which leads me to...

The fact that Embarcardero tell us "You typically need to mask and unmask exceptions when you are interacting with external code such as TWebBrowser, OLEDB, .NET assembly, ActiveX controls, and OpenGL." does not mean this is desirable more generally. I'm of the opinion that code that intentionally allows anomalous results (such as invalid floating point operations) is the only code that should need to play with exception masks, and these situations are rare outside scientific work - but that's only an opinion, obviously not shared by all. Such is life. However, it is rather unexpected to have spent a week evaluating the Core API SDK, and deciding it would do what I wanted (the OCR library failed that evaluation), to buy (acknowledging smugly the various warnings about being careful to evaluate first etc.), and then to install the serial number and discover my hard won code now fails!

No, I don't want a refund. It's a good library (though the documentation could use some work), and having the opportunity to evaluate it thoroughly before purchase is excellent, but it is very disappointing to discover (after purchase) that this is a known problem of long standing and yet nothing has been done to address it. May I recommend that you either fix the real problem, or install a fudge in your evaluation mode that intentionally generates the equivalent anomalous behaviour so that evaluators can see what they getting. And third option (a good idea anyway) is to document those functions that will need this extra layer of protection. Or should I just wrap them all to avoid surprises later?
Sasha - Tracker Dev Team
User
Posts: 5522
Joined: Fri Nov 21, 2014 8:27 am
Contact:

Re: Invalid floating point operation - in Delphi

Post by Sasha - Tracker Dev Team »

Hello GeoffW,

We will try to find a fix for the exception itself.

Cheers,
Alex
Subscribe at:
https://www.youtube.com/channel/UC-TwAMNi1haxJ1FX3LvB4CQ
Post Reply