David Heffernan

OK. What name would you give this type array [0..2] of Double

If there can be multiple users modifying the same database then this task becomes very challenging.

That's a pair not a tuple

Seems like a clear instruction to ignore future posts asking for help and instead laugh.

Whilst you can, this doesn't feel like a great idea. It's one thing returning a tuple in a language like Python with support for unpacking. But a Delphi dynamic array should be used for arrays, things where each item is a different value of the same thing. That's not the case here. They are two distinct things. Use a record, or two out params.

This is why programmers learn to use scripting languages

That's clear from the code but we don't know what it's life time is. On the face of it, exactly as you say, TList<string> or TStringList would be much more suitable. But my reticence is that there are lots of unknowns.

What is sublist and what is FHintCell. It's all just guesswork. But having pointer to pointer to character array feels odd to me.

It looks a bit odd but because we don't know for sure what all of the types and objects are, and your extracted code has arguments that aren't used, I don't think it's easy to offer specific advice. However, it's hard to imagine a scenario where this code would be the best way to do anything.

Yes that looks correct but it's also a very odd thing to do. What version of Delphi are you using?

MPL allows any license of the derived product I think. And the source code in the synedit 2 repo says the license is MPL. But asker believes that putting the code in a dll means that they don't need to worry about the license. Which is nonsense obviously. And in any case, even if it did make a difference, use a package already!!

Do remember to make sure that you meet the requirements of the open source MPL license

Are you holding records or pointers to records? Because the question only makes sense if the latter. If the latter then something needs to allocate and deallocate. But i suspect that you are doing the former.

Dynamic linking won't solve your licensing problems. Synedit, the subject of your last question, has a dual GPL/MPL license. Dynamic linking doesn't allow you to evade the licence requirements. Why do you feel that you can't adhere to the requirements of the MPL? Incidentally there was no need to make a new question to ask the same as you did in your previous question. Perhaps you didn't like the answers you got but sometimes the answer to a question isn't the one you want to hear.

It's as if you don't want people to help you.

No memory leaks when I run your code. Can you provide a minimal but complete example that we can compile directly.

No it won't. If the constructor fails then an exception is raised before the try / except is active.

Can you provide a minimal example that demonstrates the issue.

You are right, I misread the code.

Your code doesn't call Free if an exception is raised, when you pass nil as the owner. When you pass the form as an owner, the form destroys the owned object when the form itself is destroyed. You need to learn how to use finally blocks. This is a fundamental pattern that is essential knowledge.

If you try to use a DLL rather than a package, then it won't work. The simple way to think about it is that your GUI code and the components all need to share the same instance of the RTL and VCL. Packages enable that sharing. Plain DLLs do not. Yes you can. Many of us do that all the time. Is it really too much to ask why you think you cannot compile third party code into your main executable? If perhaps you think that licensing is the issue then I doubt that putting the code into a separate dynamically linked module changes anything.

Plain native DLLs aren't really practical for components. This is the reason that packages exist. So if you need the code in a separate module, use a package. But packages introduce complexity for deployment and versioning. Why don't you want direct inclusion of the code in your executable?

Don't. Best option is to compile it directly into each project. Next best is to compile into a Delphi package. Direct inclusion is much more simple.

Wouldn't it just be better to stop using XP? Doesn't even sound like you have a machine to test on which is tough for a program based on USB devices.

Then it sounds like the issue is with your USB library. You'll need to dig into this, but my expectation is that the Delphi runtime won't call that function, so it's your code that does. You'll be more experienced once you solve this!!