David Heffernan

Indeed. So one wonders why.

You can presumably remove the drop target code and just create and free a TObject instead to show that the issue is not in the drop target code. Making a minimal example is really useful.

The code in the linked SO answer doesn't leak. Update: Er, it does leak. I updated it to override CreateWindowHandle and DestroyWindowHandle, as per discussion below. Sorry!!

Usually that's wishful thinking. What happens next in this thread is that people spend many days suggesting all sorts of things that could be. That doesn't tend to be very productive. Guesswork seldom proves effective. We all know this to be true, and still we do it. Getting a stack trace from all threads in your process, during a lock up would help. Again, madExcept would give you that with madTraceProcess.

Use process explorer or process hacker to see if you are leaking gdi objects. Use madExcept leak detection tool which detects all sorts of leaks. You need to try to narrow things down.

No reason to suspect that COM+ is the problem. Surely its just a defect in your code. Hard to imagine introducing another framework is the easiest solution. In any case I think it sounds like step 1 is to identify the problem precisely.

What are you trying to achieve? What can't you achieve without using UWP?

With these issues you need to understand the hierarchy of your windows' owner relationships. The term owner is the winapi term. In VCL terms it is popup parent, not to be confused with VCL owner. Start by making a minimal reproduction and try to understand that window owner hierarchy. Read the MSDN docs on window features to understand the impact of window owner.

What's wrong with just adding the controls to a collection? Controls.Add(control1); Controls.Add(control2); Etc.

Maybe you are right. Maybe my multithreaded program doesn't work.

What are you on about. It is perfectly possible to write code that is correct, and behaves in a deterministic fashion with threads. For sure the order of scheduling and execution is not deterministic, but that doesn't mean that you can't write programs whose behaviour is deterministic. I for one make a living doing just that.

pthread_kill But don't do it. It's surely not the solution to your problem.

FYI, cross posted here: https://stackoverflow.com/questions/58858474/how-do-i-extend-the-delphi-10-3-code-editor

[Names('foo', 'bar')] TMyEnum = (foo, bar); It's kinda flaky of course because of the limitations on attribute constructor arguments being true constants. Later on I can write Enum.Name(someEnum)

I use a cache, a dictionary keyed on the type info pointer, iirc

Yes http://docwiki.embarcadero.com/RADStudio/en/Attributes_(RTTI)

It's a bug for the very reasons that you raised! When the thread was created in the constructor of `TThread` it meant that you couldn't synchronise passing state to the thread before it started.

Creating them non-suspended explicitly does what you wish also.

Do that in the constructor of the thread if you wish. No need to create the thread suspended.

That was a bug fixed in Delphi 6, and one of the reasons for the introduction of AfterCreation. I never create threads suspended.

Yes. What happens if you pass False and so don't create suspended?

I use attributes attached to enumerated types to handle this

Why are you creating the thread suspended. What happens if you don't do that?

If I actually disagreed with you, I'd produce a counter example. I don't think I have because I don't think there is one. Therefore I can't believe that I disagree.

I don't think that there was any difference regarding the streams. I think you've just mixed up the begin/end update with the streams and got a bit of cargo cult. FWIW your try/finally is not right.