Jump to content
c0d3r

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

Recommended Posts

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 by c0d3r

Share this post


Link to post

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 by Der schöne Günther
  • Like 3

Share this post


Link to post

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 by aehimself

Share this post


Link to post
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.

  • Thanks 1

Share this post


Link to post
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....

Share this post


Link to post

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

Share this post


Link to post
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.

 

 

 

 

 

Share this post


Link to post

There is another problem with Form inheritence in 10.4.1:

If you have Events assigned in the root Form like:

 

image.png.28441d201f3136a8f8f4b69bf88ab0f6.png

 

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:

 

image.png.f9ba822061016cae9ee4679d0b405a7f.png

 

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.

 

 

image.png

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×