David Heffernan

I wouldn't feel very confident about my chances of making this design work. Personally I'd be looking for a different solution.

No.

This is certainly a thing that is routinely done. https://en.m.wikipedia.org/wiki/Ephemeral_port The system has support for generating such ports, I've used it with an Indy server listening on loopback for a client in the same process. I do this to implement an application help browser using an embedded Web browser control. I don't want to use a fixed port number because I don't want to risk clashing with other services. And since I control both server and client an ephemeral port is perfect.

It's explained in the documentation http://docwiki.embarcadero.com/RADStudio/Rio/en/Activating_and_Configuring_the_Target_Platform

You have to maintain the Linux box. You have to maintain the svn server. If you have it hosted then somebody else does it all.

It's been Embarcadero for over 10 years now....

I know. I thought that Emba contributed some code to LLVM/Clang.

What about LLVM/Clang?

I haven't got time to look at this in VCL code, but my guess from memory is that you need to be overriding CreateWindowHandle and DestroyWindowHandle instead of CreateWnd and DestroyWnd. CreateWindowHandle and DestroyWindowHandle are the methods tasked with he actual creation and destruction of the window. Probably when the form is torn down it just calls DestroyWindowHandle and not DestroyWnd.

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)