Jump to content
Dave Craggs

TSplitView Inheritence

Recommended Posts

If it helps, here are images of the original and the inherited forms.

 

Dave Craggs

SplitViewOriginal.jpg

SplitViewInherited.jpg

Share this post


Link to post
Posted (edited)

Take a look at your DFM file:

https://github.com/dcraggs/Splitview-Inheritence/blob/d4e12a1141cd1a0bfb0832777ae59cf5e08b4a49/uSplitViewInherited.dfm#L53-L63

 

It contains, unnecessarily, a redundant copy of your SV: TSplitView. Even worse, the SplitView contains an even more redundant copy of the TCategoryButtons. And this time it's empty.

 

This is just one of the many(!) problems DFM serialization has with inherited forms and frames.

I roughly spend 20% of my time developing Delphi applications with dealing with DFM corruptions like these.

Make your DFM file looks something like this:

 

inherited SplitViewInheritedForm: TSplitViewInheritedForm
  Caption = 'SplitView Inherited Form'
end

And every time the IDE makes changes to your DFM file, use your version control system to revert these unwanted changes. Maybe you can make the files write protected once they are "done". I don't know if that will help.

 

 

Another example is that properties like `RowSpan` or `ColSpan` from components stored in a `TGridPanel` always get lost on subclass frames. Or complete ImageLists get duplicated on subclass frames/forms, further increasing the size of your executable.

Edited by Der schöne Günther
  • Like 1

Share this post


Link to post

Thanks for that. I'll check it out.

 

I have used inheritance for YEARS with no problems, so it's worrying this is happening with newer components.

 

Dave Craggs

 

Share this post


Link to post
Posted (edited)

There is no way around inheritance, and we have also been using the SplitView for years. I am not sure if the VCL components are to blame, or it's some general mechanism that writes the DFM files.

 

We sometimes use very deep hierarchies of inheritance (placing frames in a gridpanel, that frame gets placed on another frame, and this frame gets placed on yet another frame). When the DFM files are clean and minimal, it works like a charm.

 

It's just disappointing that I, so often, have to revert files that were silently modified (sometimes, even corrupted) by the IDE without me doing anything.

Edited by Der schöne Günther

Share this post


Link to post

Have had a play. 

 

This bit here isn't redundant:

 

  inherited SV: TSplitView
    Height = 361
    ExplicitHeight = 361
    inherited catMenuItems: TCategoryButtons

It is a reference to the components in the parent form.

 

If I delete the whole section in the dfm and show form it all looks good. As soon as I run it the buttons disappear.

 

What has worked is if I delete the section and add a button to the category buttons list thereby making a change in the DFM to that section, they all stay.

 

Could be a workaround.

 

Dave Craggs

Share this post


Link to post

I would like to agree so much with @Der schöne Günther.

I have Visual Code open on my DFMs constantly policing theIDE.

Would be nice if the IDE would handle reloads from disk better, but i would not put my moneys on it.

Share this post


Link to post
Posted (edited)
1 hour ago, Dave Craggs said:

If I delete the whole section in the dfm and show form it all looks good. As soon as I run it the buttons disappear.

Yes, that's the other fun part. Do close the views that give you trouble before you launch your application from the IDE. Because the IDE will, once again, modify (and possibly corrupt) and save these files before it they make their way into your .exe. I think even the "Save modified files" buttons get un-grayed and you can click them. You must switch to a pure .pas source file, and close the other tabs. Then, hit F9.

 

I know this probably sounds very frustrating, especially if you never ran into problems like these for years. If this is just a very special case and you don't want to adapt to a slightly different workflow, I would remove the TCategoryButtons from the form designer altogether and instead place it at runtime, most likely in the constructor of your TFrame.

Edited by Der schöne Günther

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

×