David Heffernan

Well, knowing what you are doing in the setter functions is likely important to decide how to write them. You want to take copies? And do you have one member field for each array type? Anyway, I'm also of the opinion that a branching generic method is little better than a series of overloads.

There are lots of different ways to do this depending on what the dll offers. Nobody can give you any steps without knowing how the dll exposes its functionality.

Are you sure this is right? It takes a reference to the array rather than a copy.

I mean I broadly agree. I was just trying to explain to Thomas what the post he was responding to actually said. For me it's crazy that dynamic arrays are zero based but strings are one based. Obviously I can see how we got here.

This is a strange post. The issue with multiple languages is the mix of zero based and one based indexing.

I don't disagree with that point. My point is that it was a bad idea in the first place to make strings 1 based.

It would make far more sense for strings to be zero based. They are only one based because short strings stored their length in element 0.

You can for short strings

for var item in arr do This is generally to be preferred, but sometimes you want the index as well as the item. In Python we write for index, item in enumerate(arr): print(f"arr[{index}] = {item}") The absence of such a feature, which also relies on tuple unpacking, makes such loops in Delphi less convenient. This is pretty much the only reason for still using classic for loops.

I use an EV code signing certificate

No, this is not possible in Delphi 2007. You can declare typed constants for fixed length arrays, but not dynamic arrays.

Sorry, content removed, I'm talking nonsense.

Sorry, content remove, I'm talking nonsense

Isn't the reason that Delphi is good at building GUI apps, at least it was for vcl back in the day. And it's still good for pure Win32 apps.

Yeah, use threads

You need try/finally to avoid potential leaks. There are basically two main object creation patterns that you have to learn. You can't get far without them.

Can you link the documentation you refer to so that there is no ambiguity in the question

That's easy to fix. You just make sure that they call internal methods only. Not really. You can store the FPCR to a local variable in the exported method. The thing is, the change in Delphi 12 isn't actually causing any new issues. These issues always existed. It's just a consequence of the "design" of DLLs not making FPCR part of the ABI.

One very obvious problem is that you need to write code like this everywhere. Not just at the top level. I stand by my advice before. Either: 1. Make FPCR part of the contract, or 2. Take control on entry, and restore on exit.

This is the worst advice I've seen in quite some time!!

DLLs should take charge of this. They should either make it part of their contract that the host sets the fp control state to a specific state. Or they should set it on entry, and restore it on exit. My DLL does the latter.

It's time to start using revision control

Why are you using ShellExecute. That's a deprecated function that used to be used to execute shell actions, but has been replaced by ShellExecuteEx. If you want to execute a specific program why aren't you using CreateProcess?

This is pretty epic, let's be honest. Take all the drudge out, and let us work on the brain stuff.

That's kind of a vague specification. For instance, is the data pushed or pulled? I would imagine that makes a difference.