CoDe Magazine E-Mail Column and Newsletter
Publisher's
Point:
Using Your Inheritance
|
Markus Egger
Publisher,
CoDe
Magazine
|
Visual Studio .NET introduced a great feature that was not new to
many developers, but was new to Visual Basic developers. It was a
feature that greatly increased the options for everyone who previously
based their efforts on the COM platform. Am I talking about Web
services? Xcopy deployment? The Common Language Runtime (CLR)?
Those are good guesses, but what I am talking about is
inheritance. To me, this is one of the biggest benefits introduced by
the first version of Visual Studio.NET. In fact, to me, the lack of
inheritance support was the main reason I avoided VB programming in the
pre-.NET world. It was unbelievable to me that a mechanism so
fundamental to object-oriented development was not available. The tides
have turned though, and now we have inheritance support and more:
cross-language inheritance that represents the foundation of everything
in the .NET Framework.
I am happy to see developers
using this great feature in many ways and for many different purposes.
It seems that increasing numbers of developers understand not just the
theory of inheritance, but also know how to use this powerful feature in
real-life situations. Yet there is one area where inheritance is often
overlooked: inheritance in Windows Forms.
Why is that? Frankly, the thought of re-creating forms
that behave like I want them to, re-creating buttons that look like I
want them to, and re-creating textboxes that format their input the way
I want them to, gives me the heebie-jeebies! To be honest, technically,
inheritance is used a lot in Windows Forms, as every new form that gets
created is a sub-class of a Form class. But that's not what I am talking
about.
Consider a simple scenario. Assume that you need to build
a Windows Forms application with a variety of different forms. You might
right-click your solution and choose "Add Windows Form..." from the
menu. This appears to create a brand new form from scratch, but it
really doesn't. Instead, the Designer creates a new class that inherits
from System.Windows.Forms.Form, and which looks and behaves very much as
you would expect a Windows form to behave. The class makes calls to the
Windows API to produce something that looks like a window and a form.
The class provides easy access to many of a form's features, such as the
ability to set the window's title or to specify whether you even want a
title bar. The System.Windows.Forms.Form class goes beyond a bare-bones
abstraction of a simple window, and provides features such as integrated
localization or the ability to set the "Accept" button.
Everything provided by the basic System.Windows.Forms.Form
class is great stuff, and by adding a "new" class to the project that
inherits from System.Windows.Forms.Form, you tell the compiler that you
want to create a class that is exactly the same. You end up with
something that looks and behaves like a form and you can safely proceed
to adding additional objects (buttons, textboxes, etc.) and additional
functionality to the form. To state it a bit differently: you started
out with a generic form that was just like any other form, and only
added and changed the things that were exceptional. This is why
inheritance sometimes is also referred to as "programming by
exception."
So far, so good. But the million-dollar-question is: what
are the chances that the basic System.Windows.Forms.Form class fits your
needs 100%? Pretty close to 0? How often do you go into your new form
and change the same exact property that you have been changing in all
the other forms you have ever created, like maybe the icon? All the
time? I thought so. So why, I ask, would you keep doing this? My guess
is that performing these types of repetitive tasks is not the highlight
of your developing day. The solution is simple: use inheritance the same
way you use it in other development areas, and use it the same way the
Microsoft Windows Forms team used it when they built that part of the
.NET Framework.
So how do you use inheritance like that? First you create
a Forms class the same way you would when building any new form, because
that new form really is a subclass of the default
System.Windows.Forms.Form class. Then, change whatever you want to
change. Maybe you want to change the default icon. Maybe you want to add
some functionality that manages the form's default screen position a bit
differently. Maybe you want to render the form's background in a
slightly different way. Or maybe, you are happy with the way the form
works for the time being, but want to give yourself a nice place to add
and change behavior and appearance later.
Then, whenever you create a new form class, instead of
picking "Add Windows Form..." from the right-click menu, pick "Add
Inherited Form...". You pick the Form class you created from the dialog
box. (Alternatively, you can create a default form and change the source
code so the new Windows Form inherits from your form). This way, you end
up with a new form that is exactly like the Form class you fine-tuned.
Your own Form class inherits all functionality from a default
System.Windows.Forms.Form class, so you don't have to fear losing any
functionality or incompatibility with future versions of the Framework's
Form class. You simply have a version of the form that is a bit more
powerful than it would be if you were using the "barefoot"
version.
But wait: there is more!? ? ?
Have you gotten your CoDe CDs yet?
CoDe Magazine content is also
available on CDs! If you have missed 2000 - 2002, make sure you get your
CD now while they are still available. Also, the new 2003 CD is
just around the corner! Don't miss out!
Get your CDs as
well as back issues in the CoDe store:
New Web Site Features
Have you seen our new web site? The new CoDe Magazine site allows
subscribers to read articles online and?post comments. The site
also allows subscribers to manage their subscriptions, change addresses
online, and more. Want to?know when the last issue has been shipped
to you? Find out online!?We encourage you to poke around...
We have recently also added an RSS feed to the CoDe web site,
allowing you to use an RSS Syndication News Reader on CoDe Magazine
content.
Is This Spam?
No. You receive this email because your CoDe Magazine
account/subscription indicates that you are interested in receiving
email newsletters. If you do not wish to?receive CoDe
Newsletters?by email, you can change your preferences online:
Note: It is our policy not to use a "reply to unsubscribe" process,
since this is often used by spamers to verify email addresses before
they are passed on. Using the above link ensures that this will not
happen at CoDe Magazine.
