Hello.
I can calm you down in this respect.

Some more details: The problem was with the setting in the control word that causes the FPU to throw an exception whenever it encounters "infinite" values. And I mean "encounter". Not just Infinite results, but it throws also when an attempt is made to simply load an infinite value into an FPU register, e.g. for later comparison (which was our case). The FPU control word came in set this way and caused problems. .NET only works when the control word is set to *not* throw in this case.

So, the interim workaround that I sent you was just about this - reverting the control word value. This could have global effect and change the behavior on your side (even though it does not affect precision or anything like that, just the error behavior). And that was also the reason why I said it was an interim workaround and that it was better to wait.

Our final solution does not alter the control word, so you are safe. We have changed the code so that we do not actually need the Infinite value internally (or better said, the code was changed that it does not attempt to load it into any FPU register).

Best regards

Hello.

The problem should be resolved in QuickOPC 2023.1 build 401.1 and later, now available for download on our Web site (verification: version 5.71.401.1 or later should be listed on the first page of the Setup wizard, when you run it).

Instructions: Uninstall QuickOPC on the target computer, and install the new one. You do not need to rebuild your own Delphi application.

Bottom note: This is provably not our fault (except maybe for the testing part, but that is a tough call). It is a bug either by Microsoft (.NET / COM), or in Delphi. I can create a very simple "bug-free" code with the same faulty behavior. This problem is in the settings of floating point unit (FPU). .NET expects the FPU control word to be set in certain way. But when the call is made from Delphi (in 32-bit process, and on Windows 11), the FPU control word is set differently. Either there is a requirement for certain parameters of the FPU control word in the Windows or COM world, and in such case Delphi is at fault, by calling out with improper settings in effect. Or there is no such requirement, and in such case .NET is at fault, because it should assure the proper settings at each entry point.

We have made a workaround in our code for the most common cases.

Best regards

Hello.

We will probably have the update to 2023.1 ready during Monday. If you can wait, I recommend to wait.

Best regards

Hello.
One more interim solution:

Please add following code right after 'begin' of your main program:
This should help. Please let me know if it works. We are still working on a solution on our side.

Best regards

Hello,
Yes, the log output from the demo app is basically good, as expected.

Regards

Hello.
I understand - it's unfortunate that you cannot switch to 64 bits now - but as I said, I believe we are on a good way to resolve the issue in 32 bits too.

Regards