David Heffernan

If the methods perform the same task, use overloads. What you have here looks like it should definitely use overloads.

This would suggest that there is no to level window whose text is MyTestApp

Actually it's a really bad idea. Cross process window parenting relationships just don't work out. Don't even think about it.

The error message tells you that you are supplying more arguments to a function call than expected. Look at the declaration of the function in question. Look at the list of parameters. Look at the arguments you pass. Where is the mismatch?

Well, it easily could if it would use runtime type testing, the is operator. My framework does it this way.

It's a shame you don't have enough time to do this.

The version without the owner leaks. Potentially there could be issues with popup parent also. Which form do you want to be the popup parent? Although I could be wrong on that one. I'm not sure that the framework looks at the component owner to determine the popup parent in auto mode.

AddIn express is superb

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.