TSplitView Inheritence

[Dave Craggs 7]

Hi,

 

Anyone here use TSplitView?

 

Having a problem with inheritence. If you inherit from a form with a SplitView, the ButtonCategory items from the inherited form disappear.

 

This is in Delphi 10.3 update 3.

 

I do have an example here: https://github.com/dcraggs/Splitview-Inheritence

 

Dave Craggs

[Dave Craggs 7]

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

 

Dave Craggs

[Der schöne Günther 316]

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 May 20, 2020 by Der schöne Günther

[Dave Craggs 7]

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

 

[Der schöne Günther 316]

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 May 20, 2020 by Der schöne Günther

[Dave Craggs 7]

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

[Guest]

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.

[Der schöne Günther 316]

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 May 20, 2020 by Der schöne Günther

[Dave Craggs 7]

I'll see how it goes with the workaround above.

 

Dave