02-14-2024, 06:47 PM
(This post was last modified: 02-14-2024, 07:04 PM by Alexandre Machado.)
(02-14-2024, 05:29 PM)rlebeau Wrote: As it should be. That has been the default behavior for over 25 years. If you wanted the events triggered during the (base class) constructor/destructor, you had to set the OldCreateOrder property to True (it was False by default). That property was first introduced in Delphi 4 or 5 (not sure which one, but definitely one of them), and was (finally!) removed in Delphi 11.
Aha! You are "kind of" right here, but not entirely... OldCreateOrder was false by default for new forms. For existing forms it was considered to be True if the property didn't exist in the DFM. It means in practice that any DFM file that has been around for some time has a considerable chance to end up with OldCreateOrder = True in the DFM file. This is a grep search result in a single project:
336 files need to be inspected, including 3rd party ones like ReportBuilder forms, shown in the picture.
That's a gigantic effort for absolutely no gain. Removing a boolean property and a couple of lines of code from Forms.pas unit has zero benefit for any Delphi developer, except a minor imperceptible benefit for EMB devs themselves.
Please notice that I said in my initial post that I consider the behavior of OnCreate/OnDestroy events to be correct. But the decision to break backwards compatibility removing the OldCreateOder property is definitely not.
(02-14-2024, 05:29 PM)rlebeau Wrote: If you are overriding the constructor, why are you also using the OnCreate event? Seems counter-productive to me. Use one or the other, never both together.
It should be clear to any Delphi developer by now that whenever we talk about existing Delphi code, we are probably talking about code that may be around for 20+ years.
I'm not saying that the code is correct or it should be written that way. I'm talking about code that *exists* in a real world project and, believe it or not, works as expected since Delphi 3 when it was first written. I didn't write it, I didn't review it 20 years ago, but I have to live with the consequences of EMB breaking backwards compatibility.
Fixing *real code* demands *real people* to review/fix possibly broken code and it is risky. That's the whole point.
More importantly here, when the Product Owner (very likely someone with no development background) asks your professional assessment about the *risks* involved in migrating a project from, say, Delphi 10.4 to Delphi 12 you can't just ignore this.
Guess who loses if the PO decides not to update????