Forms inheritance best practice

  • Thread starter Thread starter Daniel Billingsley
  • Start date Start date
D

Daniel Billingsley

My application will have various forms for editing my business objects. All
the objects to be edited on the various forms will either derive from a
common class or implement a common interface. Let's just say it's an
interface for sake of this discussion.

There is a lot of common functionality between the forms, of course. Using
forms inheritance seemed like a great way to reuse that common code.

Of course there are some parts of the common code that need to interact with
the interface, but the actual business object appropriate for the particular
derived form will of course be instantiated by the derived form. The
controls specific to editing that type of business object will of course be
on the derived form.

So, it seemed logical to create some abstract methods and properties in the
base form. That means the class itself must be abstract. Not so fast - the
designer complains it needs to instantiate the base class and can't because
it's abstract.

Hmmm..

That leaves me with two options that I can see. I'm just wondering which is
considered a better practice, or if there's a third I haven't thought of.

1) Declare protected fields (of the interface Type) in the base form which
could be set directly in the derived form in all the appropriate places.

2) Declare the needed methods and properties as virtual in the base class.
In the base class each simply throws a NotSupportedException since only the
override in the derived form should actually be used.
 
Ok, how about this.

I declare an interface with the properties and methods the base class needs
from the derived. I leave the implementation in the base form only throwing
the exceptions. I implement the real functionality in the derived form.

I like demanding the overrides in the derived class more explicitly this
way.
 
That really depends on the nature of your base class. I only use form
inheritance for visual features like a toolbar or menu that has to be on
every form.
 
If your objective is to provide an interface for your users to edit
your business objects then why not just use the PropertyGrid. The
property grid is a beautiful solution to this.


sayed
 
Jonathan Allen said:
That really depends on the nature of your base class.
Click to expand...

How so? This seems like a straightforward OO theory question to me.
I only use form
inheritance for visual features like a toolbar or menu that has to be on
every form.
Click to expand...

Why is that in your case? You've had problems with it or just never used it
for anything beyond that?

I'm finding that form inheritance has some weird behaviors in relation to
the designer.

I have a base form with the classic splitter layout... panel1 docked to the
left, then splitter docked to the left, then panel2 docked to fill.
Straight out of the help for creating multi-pane forms.

I put a GroupBox control on the base form.

When I go into the designer on the derived form the groupbox is moved to the
right and about twice as wide as in the base form. I jump to the code for
the derived form and the settings do not match what I am seeing in the
designer.

Put it back in the right place in the designer on the derived form. Go back
to the base form (in another project) and recompile that project. go back
to the derived form and it's moved around again.

HOW THE HECK AM I SUPPOSED TO DESIGN FORMS WITH THE DESIGNER WHEN IT DECIDES
TO DO SOMETHING OTHER THAN REPRESENT MY CODE!?!?!?!
 
Ok, I've calmed down now. LOL. I didn't mean that last yelling part to be
directed at you Jonathan. I'm sorry if it came off that way.

I was just very frustrated at VS and blowing off steam.

It turns out I'm learning that you have to understand the limitations of the
designer. One of those is that it's pretty "dumb" in the sense that it
expects to be able to write code to represent whatever it senses is going
on, but that's not always the proper code.

This caused problems with using anchored controls on base forms and then
resizing the derived form.

I'm no going to switch to using panels, docking, and the DockPadding
property to keep my controls positioned.
 
How so? This seems like a straightforward OO theory question to me.

Often times you can just have a common interface. if your lucky, you can
just that interface that expose a class that contains all the shared logic.
Why is that in your case? You've had problems with it or just never used it
for anything beyond that?
Click to expand...

The only time I've used it was for Wizard style pages where every page had
to be exactly the same size and have certain buttons in exactly the same
position. Other than that, I've never had a need for it.
HOW THE HECK AM I SUPPOSED TO DESIGN FORMS WITH THE DESIGNER WHEN IT DECIDES
TO DO SOMETHING OTHER THAN REPRESENT MY CODE!?!?!?!
Click to expand...

That's why MS has a complaint department.
 
Back
Top