Problems with Inheritance

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is anyone out there really using inheritance for serious code reuse in a
real-world setting? (As opposed to toy examples). I'm finding it to be so
unstable that it would literally take less time to code all the forms
individually. I'd be very curious to see if anyone else is having these
problems or if there is something that I am doing wrong. Or maybe it's a toy
feature that nobody's using. It's very possible that these are all designer
bugs. That would be good to know as well.

1. Forms inheritance. Intermittently, code changes to a base form (in a
separate project) are not reflected in the operation of derived forms. Full
rebuilds of both projects doesn't fix the problem. It's as if it's hanging to
a previous version of the DLL. Nothing less that recreating the form solves
the problem when this happens. There's no pattern that I can detect that
causes it to happen or not.

2. Inheriting controls from Forms classes. First of all, there doesn't seem
to be any way to do this in the designer. You have to inherit from
UserControl and then change it to the desired control by hand. Unfortunately,
once you do this it is no longer designable. Worse, again intermittently, if
try to open the derived control in the designer to modify properties after
you have made the change above, any forms which use the control will tank.
The declarations stay but the instantiation and addition of the control to
the form is missing (all in the designer-generated code). You either have to
create a new form or delete the declarations in the designer-generated code
and start over.

Aggravating in the extreme to say the least. Please tell me what I have to
do to make this work. Thanks!
 
pearsons_11114 said:
Is anyone out there really using inheritance for serious code reuse in a
real-world setting?
Click to expand...

Absolutely - in certain well-chosen situations. It's not appropriate
everywhere.
(As opposed to toy examples). I'm finding it to be so
unstable that it would literally take less time to code all the forms
individually.
Click to expand...

Forms are rarely good candidates for inheritance, IME.
I'd be very curious to see if anyone else is having these
problems or if there is something that I am doing wrong. Or maybe it's a toy
feature that nobody's using. It's very possible that these are all designer
bugs. That would be good to know as well.
Click to expand...

Inheritence is far from a toy feature, but it shouldn't be applied to
every situation. And yes, as far as I'm aware there *are* designer
issues - personally I avoid the designer for production code anyway,
only using it for prototyping.
 
1. Inheriting Forms

There is a bug(?) in the v1.1 Designer (I don't know about 2.0) that
causes the Designer to become confused when you are inheriting Forms
and projects don't get built properly because of compilation errors.

The Designer problems will persist until you close all open Designer
windows (you can leave Code view windows open... they don't affect
anything), rebuild the project successfully, then open the Designer
windows again.

My best guess is that this is because the Designer has to instantiate
the base class for a form in order to design it. If there are compiler
errors, the Designer can't instantiate the base form and it goes south.

As well, while you have a Design View window open, the Designer is
holding an instantiation of your base form in memory, and using that to
allow you to design. If you recompile a project, resulting in new base
form definitions (in dlls), most of the time the Designer will notice
and refresh the Design view windows, but it doesn't always.

In short, whenever I have trouble with designer windows, I close them
all, rebuild everything, and re-open them.

2. I have no idea what you mean by "inheriting controls from Form
class". Do you mean inheriting new Forms from existing Forms? Works
great for me... just requires a bit of code jiggering. Then again, you
mentioned in point #1 that "inheriting from Form" was giving you
problems, so this seems to be something else.

Controls that inherit from existing controls are, in fact, not
Designable. You don't lose much: just the ability to set properties,
which you can do in code anyway.

Once you've created them, though, you can put them in your Toolbox and
drag them onto your forms like any other control.

Is that what you meant?
 
I use control inheritance a lot, and I use class inheritance where it fits.
I haven't experienced these problems.
 
Thanks, Bruce. That was a very helpful answer. I'm always suspicious of the
desginer because it seems so unstable, but it's good to know specific
work-arounds that don't force you to hand-code everything. And your answer
to the second question was the one I was looking for, I just mistyped that
first sentence. Sounds like the key is work on one designer window at a time
and close it and perhaps build as soon as you want to do anything else.

What is it about visual design tools that they can never get the bugs out?
I've used many over the years, and I could break any of them at will. Maybe
there's just some inherently difficult computer science problem at the heart
of it. ;-)
 
Jon Skeet said:
Forms are rarely good candidates for inheritance, IME.
Click to expand...

Do you mean because it's a bad design idea or because it's not well
implemented in windows forms? For me it's a huge productivity gain for the
same reason as any other programming task: to hone and reuse a piece code
that's used over and over again rather than clone and copy. For example, a
reusable wizard dialog.
 
I use Windows Forms Visual Inheritance on our project. Although I have
encountered a number of problems, I was able to resolve most of them and I
have some logs about how I tackled them on my blog link below, some helpful
links and tips included.

Re: changing base class propagating to child classes, it all comes down to
controlled code generation...
 
pearsons_11114 said:
Do you mean because it's a bad design idea or because it's not well
implemented in windows forms? For me it's a huge productivity gain for the
same reason as any other programming task: to hone and reuse a piece code
that's used over and over again rather than clone and copy. For example, a
reusable wizard dialog.
Click to expand...

Well, even for a wizard dialog box I'd consider having a class which
could be provided a Panel to be the bit with the text on etc, and the
class provides Next/Prev buttons, along with events to validate etc. In
other words, use composition instead of inheritence.

However, you certainly *could* go with inheritence for wizards, and
yes, you could run into problems with the designer in that case - which
is another reason to avoid using the designer, IMO.
 
pearsons_11114,
1. Forms inheritance. causes it to happen or not.
Click to expand...

Actually it works quite well. However I found that bouth projects (base and
derived form) need to be part of the sampe solution.
The base form's project obviously has to be a class library project.
Then, I believe, for better results you should play the VS game. Instead of
creating a form and changing its base class, add to the project a new item
of type "Inherited Form". After giving a name of the item you will be
prompted to pick a base form from the projects in the solution. Choose your
base form and create the new item. Next time you change the base form you
well see a hint that you need to buid the project of the base class in order
changes to be populated ot other designers.


HTH
Stoitcho Goutsev (100) [C# MVP]
 
I often leave multiple design windows open at once. Once you get your
Form base classes stable enough you'll find that the Designer doesn't
get confused nearly as often. On rare occasion I still get this
situation in which the Designer can't show anything and starts
screaming out errors. Then I just close all of the design windows, do a
Rebuild All on each project in sequence, and then get back to work.

It happens to me only, say, once a week now, but then again my Form
base classes are pretty much in their final form now.
 
Back
Top