Board index » delphi » Re: The dark side of visual form inheritance

Re: The dark side of visual form inheritance


2003-08-29 10:13:21 PM
delphi183
I'm not sure my current project could be classified as "extensive", but
every form in the project (about 75 now) descends from a base form. I have a
base form and 3 "functional" forms (one for scrolling data, one for grid
data, one for modal editing of a row in a grid form) and everything else
descends from one of those. I have had virtually no trouble with VFI.
However, I rarely use the "visual" part of VFI. I use the base forms to
implement code, not components. Perhaps my application is unique, but it's
rare that the functionality of a specific form needs to be different from
all the others. It makes coding easier and it keeps a consistent look and
feel for the user. All in all, I like it.
Just my 2 cents.
"Daniel Mauric" <danny at neobee dot net>writes
Quote
I use vfi extensively, and was quite happy with it until recently when I
had
to make some changes in the form hierarchy. Adding/removing
controls/components is fairly easy, but problems arise when you need to
insert/remove a form class. Replacing controls high up the hierarchy can
also be painful, particularly if many inherited forms refer to these
controls in the dfm. Actually the dfm is the source of most problems, and
it
often requires manual editing. The changes that I had to make took quite
some time, and it will only get worse when the form count increases.

All of the above lead me to the conclusion that while vfi is nice it
should
be used with care. It is often stated that composition is more flexible
than
inheritance, this surely applies to forms too. I have no clear idea yet
how
to implement this, but I'd certainly like to use composition with
forms.

Comments are welcome :)

Danny


 
 

Re: The dark side of visual form inheritance

to build up forms using composition have you thought about using frames?
"Daniel Mauric" <danny at neobee dot net>writes
Quote
I use vfi extensively, and was quite happy with it until recently when I
had
to make some changes in the form hierarchy. Adding/removing
controls/components is fairly easy, but problems arise when you need to
insert/remove a form class. Replacing controls high up the hierarchy can
also be painful, particularly if many inherited forms refer to these
controls in the dfm. Actually the dfm is the source of most problems, and
it
often requires manual editing. The changes that I had to make took quite
some time, and it will only get worse when the form count increases.

All of the above lead me to the conclusion that while vfi is nice it
should
be used with care. It is often stated that composition is more flexible
than
inheritance, this surely applies to forms too. I have no clear idea yet
how
to implement this, but I'd certainly like to use composition with
forms.

Comments are welcome :)

Danny


 

Re: The dark side of visual form inheritance

I'm using GReplace as it is the best tool for these actions.
It also works for inherited forms, but replacing high up can be a killer.
If there are better tools i really would like to know!
Greetings,
Marius
"Daniel Mauric" <danny at neobee dot net>writes
Quote
I use vfi extensively, and was quite happy with it until recently when I
had
to make some changes in the form hierarchy. Adding/removing
controls/components is fairly easy, but problems arise when you need to
insert/remove a form class. Replacing controls high up the hierarchy can
also be painful, particularly if many inherited forms refer to these
controls in the dfm. Actually the dfm is the source of most problems, and
it
often requires manual editing. The changes that I had to make took quite
some time, and it will only get worse when the form count increases.

All of the above lead me to the conclusion that while vfi is nice it
should
be used with care. It is often stated that composition is more flexible
than
inheritance, this surely applies to forms too. I have no clear idea yet
how
to implement this, but I'd certainly like to use composition with
forms.

Comments are welcome :)

Danny


 

Re: The dark side of visual form inheritance

One thing that I do is to keep all childreen forms open when changing
the parent, delphi automagically update them, insted of bringing the
'Component reference not found' exception.
 

Re: The dark side of visual form inheritance

Instead of individual replies I will sum it up here.
Marius: I use GReplace too, and it does help, but the problem is that I have
to use it in the first place. No better tools that I am aware of.
Roger: Yes, that is one of that problematic cases. Given your example imagine
the following:
Change something (visual) in TForm1, then add TFormNew as a descended of
TForm1, and then fix TForm2 to inherit from TFormNew. If there are more
forms that descend from TForm1 then there's more work.
Simon: I hate the way frames behave at design time, and not all controls
work correctly when on frames. So I would rather build forms and use them as
frames, by inserting them in other forms.
Scott: All my forms descend from a base form too (~50 forms so far). I have
several 'abstract' forms: Single, List, Selection (abstract, subclasses are
SelectOne and SelectMany). These all contain both code & controls. Since you
mostly inherit code (not controls) you're less likely to have problems.
Thanks for your comments.
Danny