[Delphi 10.4] Deleting controls/components on Ancient form, Causing AVs on inherited forms!

[c0d3r 17]

Try deleting one component on an ancient form, causing all sorts of AVs on inherited forms. Turns out you have to open each inherited forms at design time after the deletion, to answer a dump question "if the reference is deleted or renamed"..., then save them.  What were these $&&*%$$ EMBR guys thinking?  The worse part was that some of inherited forms were OK no AVs and some of inherited forms weren't OK and AVs.

 

Imagine if you have hundreds inherited forms....

Edited September 22, 2020 by c0d3r

[Der schöne Günther 316]

It's not only about deleting components, it basically affects any change, like reparenting, renaming and even resizing. The best part is that you will only find out by either viewing the parent form/frame in the IDE, or at runtime.

 

The core reason is that inherited forms/frames/data modules often (not always) have extreme redundancy. Look at their DFM files. They repeat their parents content. This is especially funny when you have a huge ImageList that gets copied again and again into dozens of subclasses.

 

The only solution I could ever find is to always pay attention to your DFM files. At every commit in your source control system, do check out your DFM files! Undo changes that were added automatically although you didn't change anything.

 

When I work in Delphi with things that involve the user interface, I spend roughly 30 % of my time reverting redundant changes in DFM files.

 

 

Edited September 22, 2020 by Der schöne Günther

[aehimself 399]

Huge +1 to @Der schöne Günther. At work we have 2-5 levels of inherited frames and meet this kind of issue every single day. Reviewing DFMs became a tradition, especially since Delphi tends to move components around with +-1 pixels upon saving - even if you didn't touch them.

 

Edit: It was like this back in 10.0 Seattle as far as I can remember. It's not only affecting 10.4(.1).

Edited September 27, 2020 by aehimself

[Vincent Parrett 763]

2 hours ago, aehimself said:

At work we have 2-5 levels of inherited frames

Ouch! I stopped using form/frame inheritance a long time (ok, my code still has a few legacy instances of this) due to IDE instability. And yes @Der schöne Günther is correct, pay attention to your dfm's when committing changes. 

 

I prefer composition over inheritance these days, it's more work initially but in the long run it's just simpler for the IDE to deal with and results in less lost time restarting the IDE.

[aehimself 399]

23 minutes ago, Vincent Parrett said:

I stopped using form/frame inheritance a long time (ok, my code still has a few legacy instances of this) due to IDE instability.

Would you be so kind to explain more...? We do struggle with random IDE crashes / slowdowns / paint glitches since day 0. So far I thought it's because of our custom components....

[Vincent Parrett 763]

Just random av's, form designer refusing to open etc. So rather than using inheritance we create smaller frames and compose those with other frames. A lot of the time they are composed at runtime rather than design time though, for similar reasons (ide instability).  

[Lars Fosdal 1793]

We use frame/form inheritance for look and feel for some dialogs - but it is indeed a PITA.

[Tommi Prami 131]

Is there bug report to vote for?

 

[A.M. Hoornweg 144]

On 9/22/2020 at 8:46 PM, c0d3r said:

Try deleting one component on an ancient form, causing all sorts of AVs on inherited forms. Turns out you have to open each inherited forms at design time after the deletion, to answer a dump question "if the reference is deleted or renamed"..., then save them.  What were these $&&*%$$ EMBR guys thinking?  The worse part was that some of inherited forms were OK no AVs and some of inherited forms weren't OK and AVs.

 

Imagine if you have hundreds inherited forms....

 

When I want to safely delete a component on an ancestor form, I do it outside of Delphi.

 

I use a search tool (Agent Ransack) to find out if the component appears in any descendant forms.   I simply search the folder for all *.dfm files which contain the text  "inherited mycomponentname".  Then I simply drag &drop the resulting list of file names onto an empty Notepad++ window and perform the deletion manually. 

 

When this is done, it is safe to delete the component on the ancestor form.

 

 

 

 

 

[RonaldK 18]

There is another problem with Form inheritence in 10.4.1:

If you have Events assigned in the root Form like:

 

 

Some of my inherited Forms dont trigger that event at runtime.

In that case, the property editor of the inherited Form didn't show that event:

 

 

but I cant find any information in the DFM file with this event in the inherited form.

This does not happen in all Forms. Only with some in a big project.

It's hard to track that, because the code and DFM looks ok.

 

Didn't see that in any version before 10.4.1.

 

 

[Der schöne Günther 316]

If the inherited class does not show the event handler, then it most probably says OnClick = nil and overridding the handler from its base class.

 

But to be honest, I haven't tested 10.4.1 yet, only 10.4