David Heffernan

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!!

Why are you calling SetupDiGetDeviceProperty?

Imagine if we could specify the type of a literal ........

It depends. Get XP and try it.

This is it then isn't it. What's in the real program that causes the misbehaviour?

I don't experience this in my program. Can it be reproduced?

This should just work. The real question is why your modal message box is not on top. You should try to work that out.

No. The scheduler will put the tasks onto different threads for you. No. It means that the main thread is doing nothing, but since there are as many worker threads as cores, the CPU will be fully busy. No. Looking at your code, I guess you need to generalise it to work with an arbitrary number of tasks. This will require you to use some arrays in place of variables named 1, 2, 3, etc. It also looks like you are doing floating point division and I'm not convinced that you will count every single character, and also that you won't count some characters twice. I think you need to be more precise about the bounds of each task's work.

Your argument about intent is the closest that I have ever seen to a cogent argument on this subject. But I still don't buy it. In your argument, if you see code that sets references to nil then that indicates this "optional lifetime" pattern, for the sake of inventing a name. And your point is that if you set the reference to nil every time you destroy an instance, then you can't distinguish the optional lifetime pattern from the two more common lifetime patterns, let's call them "owned lifetime" where the object is destroyed in its owner's destructor, and "local variable lifetime" where the object is created and destroyed in a local method, and the reference is a local variable. The thing is though, when you see FAN in owned lifetime and local variable lifetime, it's unmistakeable what the lifetime is. You never think, oh, I wonder if this might be optional lifetime. That's why I don't buy the argument, and why I've never experienced the issues you describe. What I have experienced though is the pain of using a stale reference. That pain is eased if the reference is nil. And yes, we can use debug MM to write over memory when an object is destroyed, but I don't want that to happen in my release builds. And sometimes bugs only emerge in release builds.

True. But then I've never made that claim.