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;
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;
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?