OldCreateOrder and Delphi 11

[dummzeuch 1505]

Uwe Raabe blogged about the change regarding the TForm.OldCreateOrder property in Delphi 11:

 

It deletes existing entries from the dfm files.

 

While that isn't a problem if you exclusively use Delphi 11, it breaks backward compatibility with older versions. These older versions always set OldCreateOrder to False for new forms but assumed it to be True, if it doesn't exist. Once you open a form in Delphi 11 and save it, older Delphi versions will see that OldCreateOrder is missing and assume it to be True even though it was set to false before Delphi 11 removed it.

 

That has been a major stumbling stone for keeping GExperts forms backwards compatible. I always have to check the dfms before committing them to prevent disaster as some forms were using both Create and FormCreate to initialize the forms (yes that's a bad idea) and were of course expecting Create to be finished before FormCreate was called. That was the default for all Delphi versions since at least Delphi 5. But if you set OldCreateOrder to True, this is no longer the case and bad things happened.

 

I hope I have fixed all occurrences of this in GExperts.

 

But actually I would like to fix this annoying behavior. Is there a way to add OldCreateOrder=False back to the dfms when the form is being saved? Simliar to removing the also annoying ExplicitXxx entries?

 

If you have an idea how to implement this, please let me know. Mein Dank wird Dir ewig nachschleichen(*1). And I'm sure I'm not alone with that.

 

(Literally: "My thanks will forever creep after you" but simply meaning "I'll forever be thankful to you".)

[Achim Kalwa 61]

1 hour ago, dummzeuch said:

Is there a way to add OldCreateOrder=False back to the dfms when the form is being saved? Simliar to removing the also annoying ExplicitXxx entries? 

After reading your post, my first idea was to extend the GX_ExplicitFilterExpert to patch the TCustomForm.DefineProperties() method the same way as for TControl, then adding a WriteProperty('OldCreateOrder', True). But when TCustomFormFixOldCreateOrder calls "inherited DefineProperties", the code recursively calls itself, resulting in a stack overflow.

So, I don't have any good idea to solve this problem 😞

 

[Vincent Parrett 750]

I would think that one work around would be to not use FormCreate/FormDestroy and just override the constructor/destructor. 

 

Embarcadero never care about backwards compatibility - for them the only version that matters is the current version. There are plenty of other issues with maintaining forms for multiple versions.. like the IDE messing with the uses clause for things like imagelists and actionlists. 

[dummzeuch 1505]

Yes, that's what I did with GExperts.

49 minutes ago, Vincent Parrett said:

I would think that one work around would be to not use FormCreate/FormDestroy and just override the constructor/destructor.

Yes, that's what I did in GExperts, but having such a tool would still be great.

 

50 minutes ago, Vincent Parrett said:

There are plenty of other issues with maintaining forms for multiple versions.. like the IDE messing with the uses clause for things like imagelists and actionlists. 

Yes, that's another annoyance, in particular because that's totally unnecessary. My solution for these is unit aliases.

[alestr72 0]

Sorry but the OldCreateOrder property has been removed in Delphi 11. It is not so?

 

https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Classes.TDataModule.OldCreateOrder

[dummzeuch 1505]

16 minutes ago, alestr72 said:

Sorry but the OldCreateOrder property has been removed in Delphi 11. It is not so?

 

https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Classes.TDataModule.OldCreateOrder

Yes, but unfortunately that means that if you open a form in Delphi 11, save it, and open that form in an older version of the IDE (e.g. 10.4), you will end up with a form where OldCreateOrder is True, because that's the default for this property. This can cause all kinds of bugs if you use the OnCreate event. I think that was a totally unnecessary change.

[Uwe Raabe 2057]

Can't you just override ReadState and set OldCreateOrder to false after calling inherited?

 

This can be pretty simple when all forms are derived from a common base form.

 

BTW, TDataModule suffers from the same issue.

[dummzeuch 1505]

18 hours ago, Uwe Raabe said:

Can't you just override ReadState and set OldCreateOrder to false after calling inherited?

Possibly yes. I solved it by moving all code from OnCreate events to a InitForm method and call that from the constructor (or in some cases move that code directly to the constructor).

 

Fortunately I was never in the habit of using OnCreate at all - I prefer overriding the constructor - so GExperts was the only case where it mattered. Once I found out what the problem was, that wasn't too difficult.

 

What I was after was some code to put into an Expert to fix this annoying behaviour of the IDE.

Edited September 3, 2022 by dummzeuch

[Fr0sT.Brutal 900]

On 9/3/2022 at 12:55 PM, dummzeuch said:

Fortunately I was never in the habit of using OnCreate at all - I prefer overriding the constructor

Damn. While this is acceptable (though requiring more code) option for inner fields it's completely useless for initing of child controls. And I don't trust OnShow because it could be called multiple times.

[dummzeuch 1505]

32 minutes ago, Fr0sT.Brutal said:

Damn. While this is acceptable (though requiring more code) option for inner fields it's completely useless for initing of child controls.

What's the problem with initializing child controls in the constructor?

Edited September 19, 2022 by dummzeuch

[Fr0sT.Brutal 900]

40 minutes ago, dummzeuch said:

What's the problem with initializing child controls in the constructor?

Wow, you're right, all components are read after call to inherited c-tor. That's good. Adding c-tor still requires some more code but it could be fastened by templates