David Heffernan

41 minutes ago, Rollo62 said:

Yes, but from my experience, this helps to REDUCE the risk of AV's, in case of async processes

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? 

3 hours ago, Rick_Delphi said:

My lifestyle requires $150K/yr just to support it. I can't wait three to five years for a startup to take off or go belly up.

Why do you limit yourself to Delphi then? 

Do you have a question?

5 hours ago, Rinzwind said:

Seems like popupmenu's with icons are still custom drawn and do not match Windows 11 standard.

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

8 hours ago, Uwe Raabe said:

Yes, upscaling and downscaling by the same factor keeps all values intact (I provided a mathematical proof for that), but downscaling and upscaling does not. That was the main reason for my feature request: RSP-35301 - Option to design in Screen PPI but save in 96 PPI

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. 

1 hour ago, dormky said:

Again, just a badly designed API

I suggest you try to design a GUI framework that can everything that the VCL can. 

1 hour ago, dormky said:

To note ; the OnFormClose event isn't called when calling Close.

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. 

1 hour ago, dormky said:

This is like having 3 locks on your door, each looking the door in a different way

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. 

1 minute ago, dormky said:

The Windows API in this case is better than the Delphi one for reasons already outlined.

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. 

14 hours ago, NecoArc said:

oh the irony, the lib used to find memory leaks is causing memory leaks

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.

4 hours ago, dormky said:

If they implemented it in the same way (a single flag serving two purposes), I would levy the same critique. With the caveat that it least it doesn't make the API more confusing since it's internal.

Whereas as far as I'm aware, Delphi had no obligation to implement it in the same way, although it might have been a volition at the time to do a one-to-one of Windows. Which could be critiqued in itself, of course.

This makes no sense. It's logically identical. 

3 hours ago, dormky said:

Yes, and I established that it does it _internally_ and that you don't have a single flag serving two purposes, as you do in Delphi.

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

1 hour ago, dormky said:

By implementing your own ShowModal which doesn't rely on it and instead listens for a "close" event, I suppose. Maybe you could make a "Close" function which would raise this event and set the return value to the value given by argument... You know, just how EndDialog does it 😉

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

2 hours ago, David Schwartz said:

And if setting ModalResult isn't closing the form, then tossing a call to Close in there may or may not work, or may not do what you expect. 

 

This is based on my experience. YMMV.

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

2 hours ago, David Schwartz said:

Setting ModalResult can be overridden

Really, how ? 

5 hours ago, dormky said:

Yes, but the difference is that the flag is internal. We do not have access to it, nor is it the same as the value returned by ShowModal call.

Again, to close in Windows I call function. In Delphi I set a flag. Fundamentally different things.

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. 

1 hour ago, dormky said:

Then please explain ? I delphi, I write to a variable that is then monitored to close the form. In Window, I call a function. Those two things are completely different.

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. 

10 minutes ago, dormky said:

If someone else is building a house out of paper, that doesn't mean it's a good idea.

However it makes sense to build the furniture out of paper too, so in way Delphi copying this behavior makes sense. However, they didn't copy it :

> The procedure then calls the EndDialog function to set the dialog box's return value to either IDOK or IDCANCEL, depending on the message received, and to begin the process of closing the dialog box.

So here, the Delphi equivalent would calling Close and giving it the value we want to return. The flag is completely internal to Windows and cannot be set by the developer manually AFAIK.

 

So basically, Delphi's implementation is to let the dev set the flag, and regularly check for when the flag is set to trigger the closing of the form.

Window's implementation is to have the dev explicitly call EndDialog with the value to be returned.

Delphi's implementation is worse and actually doesn't have much in common with the Window one from the POV of the dev.

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

1 hour ago, dormky said:

Heavy disagree. A message/event driven environment should, you know, actually use events instead of mixing in state monitoring.

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. 

24 minutes ago, David Schwartz said:

That Close call might not even be getting executed because the assignment to ModalResult calls a method that has side-effects.

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.

8 minutes ago, David Schwartz said:

If it's a TreeView or a ListView, make sure you don't have an OnChange handler wired up -- or if you do, you want to put a flag in it that says:

 

if ignore_this then Exit;

 

And have a var at the top of the implementation section

 

var ignore_this : Boolean;

 

Set it to true before you start your loading up, and false when you finish.

 

Or you could un-hook the OnChange event before you start and replace it when you're finished.

yeah, global variables in your GUI, great idea!

6 hours ago, Brian Evans said:

As well a lot of controls with lists have a BeginUpdate and EndUpdate so you can stop visually updating the control for every change to an item. Wrap things in an Try/Finally to make sure EndUpdate is always called.

lv1.items.BeginUpdate;
try
  // add multiple items
finally
  lv1.items.EndUpdate;
end;

From the help for Vcl.ComCtrls.TListItems.BeginUpdate :

 

Prevents updating of the list view until the EndUpdate method is called.

Call BeginUpdate before making multiple changes to the list of items. When all changes are complete, call EndUpdate so that the changes can be reflected on screen. BeginUpdate and EndUpdate prevent excessive redraws and speed processing time when new items are added, deleted, or inserted.

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

36 minutes ago, A.M. Hoornweg said:

This simply wastes precious resources

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. 

6 hours ago, 357mag said:

Plus I was trying to use the debugger so I could watch the value of num in the while loop but there is no step into command. Just step over and trace into. Actually, I've never used a debugger, so I'm new to that. I'm pretty close on this maybe my paperwork is just a bit off.

Even if you don't use a debugger, get your program to print out the intermediate values in the function square. Then compare it to your expectation. 

Read the section on index specifiers

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Properties_(Delphi)