How do I close a modal form without ModalResult being set to mrCancel ?

[David Heffernan 2368]

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. 

[dormky 3]

3 hours ago, David Heffernan said:

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

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.

[Attila Kovacs 637]

If the "flag" were internal, how would I know its value in the OnCloseQuery() event?

[David Heffernan 2368]

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. 

[David Schwartz 441]

On 2/1/2025 at 4:02 AM, David Heffernan said:

On 2/1/2025 at 1:33 AM, David Schwartz said:

Setting ModalResult can be overridden

Really, how ? 

 

procedure TMain_form.WebFormClose(Sender: TObject; var Action: TCloseAction);
begin
   Action := caNone;
end;

 

Clearly obvious to even the most casual observer, right?

 

 

Edited 16 hours ago by David Schwartz

[David Schwartz 441]

On 2/3/2025 at 12:28 AM, dormky said:

Of course, I never would have chosen Delphi for a new project. But there's a lot of old 90's projects out there for which it's not cost-effective to move to a more efficient platform, so Delphi sticks around.

I use TMS WEB Core to build web apps in Delphi. They run in the browser, and don't require any knowledge of javascript.

 

I'm also learning how to use Latenode to build proxies to 3rd-party services that I can call from my client app so I don't need to implement them in a dedicated back-end service. It's similar to Zapier and Make, but I think more powerful and generalized.

[dormky 3]

On 2/3/2025 at 9:01 PM, David Heffernan said:

This makes no sense. It's logically identical.  

Sure, and using assembly is logically identical to using C. But for the vast majority of purposes one has a better API wouldn't you say ?

Bit of an overkill comparison, but the point stand. The Windows API in this case is better than the Delphi one for reasons already outlined.

[David Heffernan 2368]

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. 

[dormky 3]

3 hours ago, David Schwartz said:

 

procedure TMain_form.WebFormClose(Sender: TObject; var Action: TCloseAction);
begin
   Action := caNone;
end;

 

Clearly obvious to even the most casual observer, right?

 

 

To note ; the OnFormClose event isn't called when calling Close. However I just discovered there is a CloseModal function, which doesn't set the ModalResult to cancel in the case where the form is modal.

It does set ModalResult to 0 in the case where the Action is set to caNone.

Again, just a badly designed API. OnFormClose should be called no matter how you close the form. There shouldn't be 3 separates ways of closing the form, there should be one (taking arguments if you do want to manipulate some behavior). And said way should not be manipulating the value I want to return to the caller, as that is app data.

 

This is like having 3 locks on your door, each looking the door in a different way and you can only lock one at a time. Also the second and third lock each turn on a different porch light when you use them after 22:00.

 

[David Heffernan 2368]

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. 

[David Schwartz 441]

I think the problem we're sort of debating here is abstraction levels. The last time I looked at any code required to program a Windows Message Loop was maybe 1993 ... I might have spent one day messing with it and just wanted to throw up. Thus, I was familiar enough with it to recognize what a HUGE accomplishment it was that Delphi was able to totally hide it!

 

That said, it took me a while to get comfortable with Modal vs. Modeless forms and the quirks they have at their edges. Over the years, I've seen so much code where the authors of certain forms were NOT really aware of the differences, which is usually when the app's Architect mandated a specific calling sequence for creating and disposing of forms that was likely an attempt to impose some (misplaced) consistency everywhere in the app. This always leads to some strange contortions in certain places in the code.

 

I'm consistent enough in my own use that I pretty much don't worry about it. It's when I have to deal with code written by several different devs who themselves aren't consistent. 

 

I've got other beefs about how forms are managed, or mis-managed, by most Delphi devs, but that's more of a religious debate that nobody ever wins. (It's what inspired my CodeRage 9 talk.)

 

Anyway, it seems reasonable that the normal abstraction levels that we're using to create and interact with forms should reflect a consistent implementation under the hood. I doubt 90% of Dephi programmers have ever seen what's involved in the Win Msg Loop, nor should they need to be aware of it. Except for the quirks that David points out. (Or why, although Forms are normal objects, nobody wants to create or use normal properties to move data in and out of them like every other type of object they'd do that for... but I digress.)

[Anders Melander 1861]

37 minutes ago, David Schwartz said:

The last time I looked at any code required to program a Windows Message Loop was maybe 1993 ... I might have spent one day messing with it and just wanted to throw up.

Huh?

var Msg: TMsg;
while (PeekMessage(Msg, 0, WM_SETCURSOR, WM_SETCURSOR, PM_REMOVE)) do
begin
  if (Msg.message = WM_QUIT) then
  begin
    PostQuitMessage(Msg.wParam);
    exit;
  end;

  DispatchMessage(Msg);
end;

 

[Brandon Staggs 327]

8 hours ago, dormky said:

Again, just a badly designed API.

You keep demonstrating for us that you do not even understand the API. Your original question would have been answered by just looking at the documentation for ShowModal, or by examining the source code to see how the modal loop is implemented. You wouldn't bother to do that, and you feel qualified to make pronouncements on the overall design quality.

 

Maybe let it go.

[Brandon Staggs 327]

4 hours ago, David Schwartz said:

The last time I looked at any code required to program a Windows Message Loop was maybe 1993 ... I might have spent one day messing with it and just wanted to throw up.

I am fortunate to have learned Win32 API before anyone was doing decent abstractions of it. (I tried OWL after that and it was terrible.) 

 

There is nothing weird about a windows message loop. You get a message and decide what to do with it. And as long as you can understand the difference between sending a message and posting a message, it's easy. But, you have to read documentation, which appears to be a very sore point for some people.

 

The VCL is just a very good layer on top of this that allows for direct object oriented design. 

 

I don't buy your claim that 90% of Delphi programmers don't know about windows message loops. To be certain, a good Delphi developer will have to learn it at some point, unless they are not involved with UI development.