dormky

In Data.DB, the dataset events are defined as TDataSetNotifyEvent = procedure(DataSet: TDataSet) of object; This means that such code as MyTableTest.BeforeDelete := procedure (d: TDataSet) begin LogTableOperation('MyTableTestBeforeDelete'); end; not valid. Is there anyway of casting this ? I'd rather not define a procedure in my data module for every event of every table...

For most cases, I would recommend using the delphi-provided libraries instead of rolling your own, see https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Math.InRange

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 🙂

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.

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.

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.

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.

Depends on the project of course, and secondarily on my current skillset. For the project that spawned this thread, I probably would have gone with WPF, which would have given me easy access to the .NET ecosystem which would be useful since there's a lot of places with custom drawing, while the rest of the interface is very basic.

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.

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 😉

Hey, bad design doesn't mean it's not useful. I still use a car whose AC is less powerful then a fart lol.

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.

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.

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.

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).

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.

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.

"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.

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.

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

>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.

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".

That's what I ended up with yes

I have a TImage and a TDrawGrid. Calling BringToFront() on TImage does not put it above the drawgrid, what am I supposed to use ? UFormMain.dfm UFormMain.pas

I want a specific loading icon, not a pre-made windows one.