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

[dormky 3]

So I just made a form where the user can double-click in a list to make a selection, with this simplifed code :

 

procedure TTestForm.DBGrid1DblClick(Sender: TObject);
begin
  ModalResult := mrOK;
  Close();
end;

However in the call to Close, there's this code :

procedure TCustomForm.Close;
var
  CloseAction: TCloseAction;
begin
  if fsModal in FFormState then
    ModalResult := mrCancel
  else
    // stuff
    end;
end;

Okay that's very nice of you Delphi, but you're overwriting my stuff. How am I meant to programmatically close a form AND set the result ?

 

Thanks 🙂

Edited 10 hours ago by dormky

[Lajos Juhász 303]

You should write:

 

procedure TTestForm.DBGrid1DblClick(Sender: TObject);
begin
  ModalResult := mrOK;
end;

There is no need to call Close at all. You can thank later to Delphi for implementing correctly.

[DelphiUdIT 205]

Look at this: https://docwiki.embarcadero.com/Libraries/Athens/en/Vcl.Forms.TCustomForm.ModalResult

 

Like @Lajos Juhász said, if you set the ModalResult at value different from mrNone the Form will close when the actual procedure will exit;

[dormky 3]

Jesus Christ, that is awful design. It's amazing, everytime I encounter a situation where I ask myself "how am I meant to [thing] with this framework", the answer is always "we implemented it, just in the most non-sensical way possible lol".

[David Schwartz 440]

46 minutes ago, dormky said:

So I just made a form where the user can double-click in a list to make a selection, with this simplifed code :

 

procedure TTestForm.DBGrid1DblClick(Sender: TObject);
begin
  ModalResult := mrOK;
  Close();
end;

 

Unless you have a clear understanding of ALL the hidden things that Delphi does, you should NOT DO ANY OF THEM!

 

"Hoping you're right" is not a reliable way of writing code.

 

That Close call might not even be getting executed because the assignment to ModalResult calls a method that has side-effects. One of those side-effects is that the assignment is NOT made and is ignored. I've seen that happen from time to time.

 

It's best to avoid any kind of state-altering logic inside of event handlers, because they can end up causing infinite loops, or triggering other things that you aren't aware of. What you're doing here can alter MULTIPLE states!!!

 

As a result, the DB could be on a different record or even closed when the ShowModal gets control back. 

 

Just. Do. One. Thing. At. A. Time.

 

 

Edited 10 hours ago by David Schwartz

[PeterBelow 244]

24 minutes ago, dormky said:

Jesus Christ, that is awful design. It's amazing, everytime I encounter a situation where I ask myself "how am I meant to [thing] with this framework", the answer is always "we implemented it, just in the most non-sensical way possible lol".

You are wrong, the design makes eminent sense for a message/event driven environment like Windows. A modal form has its own internal message loop and that needs a way to figure out that it should exit the loop. Modalresult <> mrNone is that condition.

[David Heffernan 2364]

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.

[dormky 3]

45 minutes ago, David Schwartz said:

Unless you have a clear understanding of ALL the hidden things that Delphi does, you should NOT DO ANY OF THEM!

 

"Hoping you're right" is not a reliable way of writing code.

 

That Close call might not even be getting executed because the assignment to ModalResult calls a method that has side-effects. One of those side-effects is that the assignment is NOT made and is ignored. I've seen that happen from time to time.

 

It's best to avoid any kind of state-altering logic inside of event handlers, because they can end up causing infinite loops, or triggering other things that you aren't aware of. What you're doing here can alter MULTIPLE states!!!

 

As a result, the DB could be on a different record or even closed when the ShowModal gets control back. 

 

Just. Do. One. Thing. At. A. Time.

 

 

>Unless you have a clear understanding of ALL the hidden things that Delphi does, you should NOT DO ANY OF THEM!

>"Hoping you're right" is not a reliable way of writing code.

Sorry for not begin able to remember all of the documentation, and sorry that I can't afford to read all the codepaths for every call to the framework I make.

No one on planet Earth understands all the hidden things that Delphi does, because AFAIK everyone on earth is human with a limited ability to conduct logical reasoning.

 

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

That's just plain wrong, unless you are not using TForm. ModalResult is a read/write property to a private variable, there's no function call.

 

>It's best to avoid any kind of state-altering logic inside of event handlers

How do I program anything then lmao. Also my code was simplified, there are guard conditions in the actual code.

Edited 9 hours ago by dormky

[dormky 3]

41 minutes ago, PeterBelow said:

You are wrong, the design makes eminent sense for a message/event driven environment like Windows. A modal form has its own internal message loop and that needs a way to figure out that it should exit the loop. Modalresult <> mrNone is that condition.

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

[Anders Melander 1848]

26 minutes ago, dormky said:

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

If you use ShowModal then you are using the modal loop built into the VCL which relies on exiting the loop when ModalResult<>mrNone.

 

If you disagree with that design then don't use ShowModal; Use Show and build your own modal handling around it. And good luck doing that without a loop which monitors some kind of state flag.

 

I don't think you have thought this through.

[dormky 3]

6 minutes ago, Anders Melander said:

If you use ShowModal then you are using the modal loop built into the VCL which relies on exiting the loop when ModalResult<>mrNone. 

 

If you disagree with that design then don't use ShowModal; Use Show and build your own modal handling around it. And good luck doing that without a loop which monitors some kind of state flag.

 

I don't think you have thought this through.

Saying "if you don't like it don't use it" is not a valid response to fair criticism of, in this case, the inconsistencies of design choices. In general such a response is indicative of a lack of an actual argument in favor.

Edited 8 hours ago by dormky

[DelphiUdIT 205]

58 minutes ago, dormky said:

That's just plain wrong, unless you are not using TForm. ModalResult is a read/write property to a private variable, there's no function call.

Be careful when interpreting "objects", whether they are properties, variables, or other.

Granted that as you say there is only one assignment, you do not know what an assignment can trigger. And the same encapsulation paradigm makes sure that the true nature of the property is hidden from you (it can be a reading of a variable, a writing, a function or triggering a series of delayed and events).
Try to think what "triggers" a simple assignment of a property such as a connection to a DB (...Connected := True;).

It is necessary to document yourself, in the absence of experience. This must always happen when dealing with a new topic.

[dormky 3]

Just now, DelphiUdIT said:

Be careful when interpreting "objects", whether they are properties, variables, or other.

Granted that as you say there is only one assignment, you do not know what an assignment can trigger. And the same encapsulation paradigm makes sure that the true nature of the property is hidden from you (it can be a reading of a variable, a writing, a function or triggering a series of delayed and events).
Try to think what "triggers" a simple assignment of a property such as a connection to a DB (...Connected := True;).

It is necessary to document yourself, in the absence of experience. This must always happen when dealing with a new topic.

"Property triggers" such as Connected := True are only for properties that point to a function ; this isn't the case for ModalResult, which just read/writes FModalResult.

[Anders Melander 1848]

38 minutes ago, dormky said:

the inconsistencies of design choices.

The inconsistency, as you call it, is by design and just because you want the design to be different doesn't make the design wrong.

 

Even Windows' own modal dialog function works the same way; Internally it implements a message loop which exits once a flag has been set (by the EndDialog function).

[David Heffernan 2364]

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. 

[Brandon Staggs 319]

2 hours ago, dormky said:

It's amazing, everytime I encounter a situation where I ask myself "how am I meant to [thing] with this framework", the answer is always "we implemented it, just in the most non-sensical way possible lol".

It's not nonsensical at all and it is based on basic Windows event driven design that goes back eons. It's the whole point of using ShowModal to get a modal result, so that result is going to be set for you if you call Close. Just browse the VCL source code to see how it is meant to work, or read the documentation. 

 

Quote

To close a modal form, set its ModalResult property to a nonzero value.

 

Edited 7 hours ago by Brandon Staggs

[dormky 3]

9 minutes ago, Anders Melander said:

The inconsistency, as you call it, is by design and just because you want the design to be different doesn't make the design wrong. 

 

Even Windows' own modal dialog function works the same way; Internally it implements a message loop which exits once a flag has been set (by the EndDialog function).

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.

[dormky 3]

11 minutes ago, David Heffernan said:

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. 

I did learn and I'm already coding another feature ^^ I just like arguing with strangers on the internet. You often learn a lot of things indeed.

[dormky 3]

13 minutes ago, Brandon Staggs said:

It's not nonsensical at all and it is based on basic Windows event driven design that goes back eons. It's the whole point of using ShowModal to get a modal result, so that result is going to be set for you if you call Close. Just browse the VCL source code to see how it is meant to work, or read the documentation. 

That's one of my main gripes with VCL, reading the code is awful because it has basically 0 comments. Had they just put "// Setting this to a value other than mrNone triggers the closing of the modal form" I would have understood things immediately, because yes the first thing I did was open the VCL code of Close() and ModalResult.

Good code would have either set this comment, or just have a comment pointing back to ShowModal, ie "// See usage in ShowModal", which is actually what most modern frameworks tend to do nowadays. I rather like it as it will solve your questioning in 90% of cases, with the rest needing actual documentation (which you can also put in comments).

Edited 7 hours ago by dormky

[David Heffernan 2364]

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. 

[dormky 3]

3 minutes ago, David Heffernan said:

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

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.

[Brandon Staggs 319]

45 minutes ago, dormky said:

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.

I think you may be helped by learning how Win32 development works. This is basic stuff, and I don't mean that in a demeaning way. But it is always a bad approach when you come at an existing framework of 30 years and assume that you know better how it should have been designed, when you clearly haven't even read the basic documentation that comes with it. I linked for you the page of the documentation on ShowModal that explains exactly how this works, in case the source code was not clear enough.

 

Your complaints about how ModalResult works ignore the typical use case where a modal result is assigned to buttons on the form. There is no need to call "close" on a modal form in Delphi, and if you think you should call close on it, you likely have a design flaw or a flaw in your understanding of how it is supposed to work. Also, you should think about the ramifications of your method of calling Close and then still being able to do things with the form's instance after that.

 

Why are you so resistant to learning the framework?

 

45 minutes ago, dormky said:

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

This is more like someone telling everyone at a work site that they don't know the right way to do their job, when that person hasn't spent any time learning construction and the workers have been doing it for years.

Edited 6 hours ago by Brandon Staggs

[dormky 3]

You don't seem to get that I understand how it works. But it working doesn't mean it couldn't be better (way better). There's a reason Delphi is a dead language (just look at the average age of developers here), and that's because the design choices made at both the language and framework levels have been replaced by better alternatives.

 

This is way I assume I know how it could have been better designed, become I know and use better alternatives. Those alternatives aren't perfect either, but they are better.

This also doesn't mean Delphi wasn't a good framework compared to the competition 20 years ago. But that was 20 years ago, and Delphi has not improved (I mean we're still writing imperative UI code for Christ's sake), meaning the design choices that were bad but not worse than the competition are now just bad.

[Brandon Staggs 319]

4 hours ago, dormky said:

Okay that's very nice of you Delphi, but you're overwriting my stuff. How am I meant to programmatically close a form AND set the result ?

 

10 minutes ago, dormky said:

You don't seem to get that I understand how it works.

I definitely don't "get" that. I think it's very unlikely.

 

You're one of those people who assumes every gap in their knowledge is due to someone else's error. It's a waste of time to try to help people like that learn something.

[Attila Kovacs 634]

Must be exhausting attending Delphi's funeral every year just to realize it's still here.