David Heffernan

I though we were talking about the cause of the access violations in your code. But if I've misunderstood, I'm sorry.

It's not going to be a defect in Windows. It's going to be a defect in the code you are compiling. That is your starting mindset. Perhaps somebody else wants to debug your large and complex code. But if you made a minimal reproduction and posted it here I'd expect a better chance of engagement.

ResumeHandle should be PDWORD_PTR. Probably other types are declared incorrectly. Check all declarations against the header files. Ask yourself which is more likely. Is it a bug in your code, or a bug in the Windows code?

Would be nice to look at code directly in the post rather than have to download some ZIP file

It's probably XP. Cant you get a computer fit for 2022?

Extremely hard to tell what is happening here with two seemingly unrelated screenshots.

Not supported by the IDE

This is pretty odd. Times have changed. Visual Studio is a great IDE. There are lots of tools and IDEs that are good and won't cost. Why are you so set on Embarcadero tools? It seems like the wrong approach for VST3. If your subscription lapses then it's over. You can't upgrade. You need to buy a new license if you want to get a new version. Very bad model in my view.

Yes they can.

Why would you need a single library?

The Windows API functions have the same name no matter which language you call them from. This just hunts out a window by name and class, finds its first child window, and makes this window be its child. However, your real problem is that, with probability > 0.99, cross-process parenting isn't a viable solution for any problem. You say that your knowledge of winapi is not good. Well, it's going to be impossible to write this program without good knowledge of winapi. If at any point in time, you find yourself not knowing something, you must study until you acquire that knowledge. Or hire somebody that already has the knowledge.

Thus is exactly what I do and it's really not difficult. The only challenge is header file translation. Having said that, this is true for libraries with a C style interface. If it's C++ classes then you need to wrap them which is more laborious.

This blows my mind. The try/finally is to protect the resource. So you must enter the try immediately after the resource has been acquired. I suggest that you read Dalija's book on memory management.

And then you need to call a few more methods and then you risk with hell. Or you need to pass the form reference to another method and you don't have it any more. So you change back to local variable pattern. Now have you multiple different patterns for the same task. Which is fine if the different patterns bring significant benefit. But they don't. So use a single unified pattern.

If using a local variable with the basic try finally, Create, ShowModal, Free pattern is complicated and requires simplification, then I think you may have deeper problems.

Very hard to understand why you'd want to give away all the knowledge of your domain that is in your delphi code and be determined to work on the xml for this. But if you want to validate the xml because your mind is made up, then crack on.

You can understand what I wrote that way if you want. But as I explained I never intended the meaning to be that a string is the same as the Delphi type array of Char. As I explained I intended to use the word array in its general sense. For instance an array in C# is not assignment compatible with a Delphi array. Does that make a C# array not an array?

I didn't say they were interchangeable. A Delphi string is an array of elements of type Char. The documentation says: "A string represents a sequence of characters." Wikipedia defines an array here: https://en.m.wikipedia.org/wiki/Array_(data_structure) So I guess perhaps what may be confusing here is maybe you think I am saying that a Delphi string is a Delphi dynamic array, TArray<Char>. I'm not saying that. I'm using the general computing usage of the word array.

No, viewing a string as an array of char is pretty reasonable. I mean your argument could also be used to say that TArray<Integer> is not an array of integer because of the meta data. And when you do PChar(someString) to pass a null-terminated array of char to some external library, the compiler just passes the address of the first element. (Yes, I know about the empty string special case)

In Delphi a string is essentially a 1 based array of char

Imagine a world where Embarcadero weren't the only supplier of dev tools

The old code won't stop working. It's unrealistic to expect developers to expend extra time supporting legacy compilers and systems. It's no fun doing that.

Why are you asking the same question in multiple topics.

Apache POI seems to be the go to library.

Then toss a coin. Expecting people to give you insights about your program's performance is a coin toss. May as weel save time and do it yourself.