David Heffernan

I do, sometimes, use overloaded methods. You are simply not going to learn anything by asking people to tell you how the decisions to make when they don't have the necessary information to make them. You need to understand concepts but you just seem to ask us to tell you what to do in a specific case.

I don't think an answer to that question will help you.

Parsing the detailed map file is probably the easiest way to do this is a large project. If you know you have dependencies on initialization order, I'd solve the problem by removing those dependencies.

It's not an effective way to learn. A really good book is what you need. In my opinion.

No. The caller has to tell the callee what to do. The callee needs to get the information from somewhere. I wonder, do you have any good books on software design? I really don't think this sort of question has proved fruitful.

Window text is simple an attribute owned by the window. Programs can do what they want with it. Top level windows typically display it in the caption. Edit controls display it as the text to be edited.

It not the caption. Its the window text. By default the system uses that text as the caption, but it is possible to have windows with no caption, that do have window text.

Read the documentation. It's the text of the window. Documentation is always the first port of call. Don't guess. You talk about the name of the application. Well, an application name isn't something well defined in programing terms. There may be conventions that the executable file has a name that matches what you think of the application name. But nothing enforces that. You need to decide on the right way to identify your process. If you try to kill windows with the class name TMainForm then there will be collateral damage. You'll kill my program's main window! So, try to work out how to robustly identify your process.

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.