David Heffernan

As a broad rule, you should never call ShellExecute. It's long since been replaced by ShellExecuteEx. The only reason you need to know why, is that ShellExecute doesn't report errors correctly. ShellExecuteEx does. And in this case, as in so many cases, as Remy already pointed out, CreateProcess is correct. Whenever you are creating a new process, you use CreateProcess and not ShellExecuteEx. The latter is for executing shell verbs.

This one is easy to debunk. Exceptions raised in a constructor then lead to exceptions in the destructor. This is the entire reason why Free exists.

I get all the arguments that using FAN in a destructor is pointless, because how can you using that reference beyond the destructor. And I understand the argument for using it in a reference for an object that exists optionally, and can be destroyed outside of the destructor. What I don't get is what the downsides of using FAN are. What are the drawbacks?

Simple. Understand the problem, and write your code so that it works 100% of the time. It's one thing that you aren't able to do so. That's your problem. But to come on a site like this and recommend that others work like this is wild. How about you retract this terrible advice?

Who settles for reducing risk when you can eliminate it?

@Henry Olive A Delphi programmer will be able to come up with the code give the information above. There is documentation and VCL source. If you don't have a Delphi programmer on your team you have bigger problems.

I'm thinking of publishing my solution under a GPL copyleft style license. Will that be acceptable?

Why do you limit yourself to Delphi then?

Do you have a question?

I still modify the VCL to let the system draw the menus and provide PARGB32 bitmaps because the VCL code still doesn't get them right. When was Vista released??!!

I guess problems still arise when forms move back and forth at runtime. Because then you can't avoid down scale and then up scale.

The reason this is not optimised away is that it would take development effort to do so but would bring no benefit to anyone.

I suggest you try to design a GUI framework that can everything that the VCL can. Well, not for modal forms. Which makes David's post hard to fathom. It is called when closing modeless forms. Modal and modeless are very different. Again something that you see in the Windows API. It's more like needing different keys to lock your house and your car. Different problems tend to lead to different solutions. The bottom line here is that modal forms run in a dedicated message loop, and modeless forms run in the message loop of their owner. I don't think you appreciate this yet. Writing a raw Win32 program in C in the Petzold style might help you.

I seem to have lost track. In Delphi you write ModalResult := mrOk; In Windows you write EndDialog(hDlg, ID_OK); Explain why this is better. Because I cannot see it. Mostly I see you having not read the documentation and trying to blame the API design.

No, FastMM is not causing leaks, you have not identified the problem yet. The first thing to do is stop looking at task manager. Use the leak reporting mechanism to identify leaks.