David Heffernan

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.

This makes no sense. It's logically identical.

Well, you don't know how Windows is implemented internally. Not that it matters. Conceptually it's the same mechanism.

EndDialog does it exactly the same way as Delphi does it, we already established that.

No, that call to Close should never be made. No ifs and buts. Stop guessing at how the system works. Really, how ?

Windows API can't expose a flag directly so has to provide a function to set it. You are incapable of learning, no wonder this is so hard for you.

Imagine if you would read documentation. Like that for EndDialog. And imagine if the documentation for EndDialog said this: EndDialog does not destroy the dialog box immediately. Instead, it sets a flag and allows the dialog box procedure to return control to the system. The system checks the flag before attempting to retrieve the next message from the application queue. If the flag is set, the system ends the message loop, destroys the dialog box, and uses the value in nResult as the return value from the function that created the dialog box. So yeah, it's exactly the same as the Delphi mechanism. Because that's how modal dialog are implemented in Windows.

Actually the Delphi approach is just the same. You just don't understand how EndDialog works.

Instead of ranting, perhaps you should take the opportunity to learn something and take advantage of it in the future. We all make mistakes. Failing to accept the is how people don't develop.

Wow. This is so wrong. That call to Close is definitely getting executed. Setting ModalResult doesn't raise an exception. Which would be the only way to avoid Close getting called.

yeah, global variables in your GUI, great idea!

As stated in the OP this is already being used. Virtual mode is the only answer.

I mean, the memory can get paged out again so it's not that terrible. Another issue is that the paging system can't share the memory between processes if it's in memory rather than loaded off disk. I still don't understand what actual problem people who want to make their executables a few mb smaller are trying to solve.