David Heffernan

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

19 minutes ago, Markus Kinzler said:

And using other people work is quite the opposite of contribute to it.

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

20 hours ago, Stefan Glienke said:

Emba does not contribute to open source - especially not GPL

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. 

2 minutes ago, Stefan Glienke said:

The point is that DestroyWnd is never called on the TForm (tested with 10.3) thus FDropTarget never destroyed.

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

1 hour ago, Steve Maughan said:

To me this implies it's something to do with Windows 10.

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.

4 hours ago, Joseph MItzen said:

Hee hee, I'll leave you with my favorite quote from Lee's paper then (in jest!)....

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

19 minutes ago, Joseph MItzen said:

Threads are inherently nondeterministic 

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

1 hour ago, Lars Fosdal said:

How do you associate the string attribute(s) with each enum value?

[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)

22 minutes ago, Lars Fosdal said:

@David Heffernan - Do you scan the rtti attributes once in a class init method/first use, or do you fetch the attributes at each use?

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

49 minutes ago, Mike Torrettinni said:

Are you talking about TCustomAttribute, like this answer: https://stackoverflow.com/questions/2134120/delphi-2010-rtti-explore-enumerations/2620883#2620883

Yes

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

2 minutes ago, Anders Melander said:

That must have been around the time when I stopped reading the documentation 🙂

I can't see why it would be classed as a bug though.

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.

Just now, Anders Melander said:

I think I'll continue to use the create-suspended pattern anyway since it explicitly does what I wish.

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