Re: Forms inheritance and templates

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Thanks for you comments guys. I struggle to see any real advantage to
templates for forms, it seems to be "sold" as a way to keep a familiar look
and feel to the app and allow quick creation of forms but in reality the
familiar look and feel cannot be changed easily once you have created dozens
of forms from the template since changing the template has no effect on
"derived" forms whereas with inherited forms it does.

I have hit on a nice problem that highlights what Jack is saying about using
inheritance correctly and avoiding having the delete controls. If you have a
base form with a TabControl that has one tab that is common to all derived
forms, then in the derived form you add a specific tab - the derived tab
will always appear first and you can't get it to appear in any other order.
I suspect this is because the base class controls (ie tabs) are created
before the derived class controls and the tabs in the tab control are
ordered as they are created. You can delete these tabs in the derived forms
load method and then recreate them buts its messy code and your just making
more work for yourself, something derived forms are there to solve.

--
Best regards
Mark Baldwin

"Bill Woodruff" <billw@xxxxxxxxxxxxxx> wrote in message
news:uhUcsPHmIHA.3512@xxxxxxxxxxxxxxxxxxxxxxx
Jack Jackson wrote :

"Not at all. The inherited form may have no interest in some of the
events
handled by the base class - it wants the base class event handling to
occur.
To arbitrarily not service any event handlers in the base class just
because
a form is inherited seems like madness to me."

I think you have not quite understood my comments. We probably agree more
than you think : I would say any inherited form that for some reason
doesn't
use any major part of its "parent's" functionality and events is poor
design. I bet you, like me, have ended up re-designing forms so that a
first
prototype form, from which other forms have inherited, ends up being
"forked" so that it becomes two form classes : one of which is the core
functionality, objects, and events which all inherited forms use, and
another which adds some additional features that all its descendants will
use. I've even used (gasp) the Templates facility once in a while to avoid
doing this.

"Usually when you use inheritance you are trading some level of
obfuscation
(by hiding code in various levels of inheritance) for not duplicating
code.
I think by careful documentation and thought about what functionality
belongs in what class the result is much better than not using
inheritance."

Here we are in complete agreement :) And very eloquently stated, I might
add ! My objection is not to the core idea of event broadcasting which is
one of the most wonderful things in .NET, but to the sticky wickets I have
gotten into using inherited forms. I would argue that inherited forms are
appropriate in some cases (top-down design scenarios, particularly), and
very potentially deadly in other scenarios (like prototyping).

"If inherited classes need to remove controls from the base class, then I
suggest that those controls should not be in the base class.

If you wire up an event in a base class, then all inherited classes should
use that event as defined in the base class.

If you want inherited classes to be able to optionally use the event
behavior of the base class, then you need to wire up the event in a way
that
allows the inherited classes to make that choice. The way I do this is to
copy what the .NET framework does.

Suppose my base class has an Edit button. In the base class I have a
handler for the Edit button Click event that calls a "Protected
Overridable
Sub OnEditClick()" method. In that method is the base class code to
handle
the event. If an inherited class wants different behavior, it overrides
the
method."

Your comments are eloquent and interesting, and appreciated. The last time
I
tried (in C#) to implement this by making the procedure in the base class
public virtual, and the implementation in the inheriting class public
override , I was able to avoid calling the base class event, but my button
event handler was called twice for unknown reasons ! However, I was not
using the level of indirection you have described in your example (for
which
I do not know off the top of my head the equivalent in C#) : perhaps
therein
lies the rub.

It is good to continually re-evaluate what one assumes ! But I remain
convinced that inherited forms in any circumstance where usage is not 100%
consistent with the base class they inherit from ... and only ADDS
additional controls and functionality ... is a sticky wicket and liable to
distract me in real world development.

thanks, Bill





.

Quantcast