As a fairly public figure in the Windows developer community, I
often get asked if I think that .NET is going to "take off." I
always answer the same thing; it's not a matter of "if," it's a
matter of "when." Microsoft's .NET Framework has so many benefits
that even as a grizzled old C++/Win32 guy, I wasn't able to resist
the siren song of a managed development environment. It's ironic
that the temporary dip in the economy has caused folks to avoid
anything new just when .NET comes along to deliver significant
reductions in time to market and cost while simultaneously
increasing code quality. The organizations that have already
adopted .NET know that it's going to have a long and happy life,
especially as it gets pushed further and further into Microsoft's
own plans for the future of the Windows platform, both on the
server and on the client.
The primary serverside technology in .NET is ASP.NET, which
provides the infrastructure needed to build web sites and web
services. ASP.NET provides the reach to deploy web sites to anyone
by aiming at the baseline of features provided by the middle
generation web browsers. To provide the highest level of
functionality possible, ASP.NET does most of the work on the
serverside, leaving the clientside HTML as a thin wrapper to
trigger serverside requests for new pages of data. The serverside
handles practically everything, from data manipulation to user
preferences to the rendering of simple things like menus and
toolbars. This model provides the greatest availability across
operating systems and browsers.
If, on the other hand, your targeted customers are Windows
users, an HTMLbased experience limits the users to a lowestcommon
denominator approach that is unnecessary. In fact, in an attempt to
provide a richer clientside experience, many organizations that
know they're targeting Windows users require specific versions of
Microsoft's Internet Explorer (IE) web browser. However, as soon as
that happens, IE becomes less of a browser and more of an HTMLbased
application runtime. And for that purpose, the HTML object model is
fairly primitive, often requiring a lot of work to do things that
are normally simple (like keeping track of a user's session state).
If you're going to be targeting Windows users, the .NET Framework
provides a much richer set of objects for building interactive user
interfaces.
This brings me to the subject of this book: Windows Forms
(WinForms). WinForms is the face of .NET on the client, providing a
formsbased development environment meant to provide the best of the
UI object models that have come before it. In addition, it provides
one feature that no Windowsbased development framework has provided
to date the deployment features of HTMLbased web applications. The
ability to combine the richness of Windows applications with the
deployment of web applications signals a completely new world for
Windows developers; one that makes me more than happy to give up
the mess of unmanaged code.
Audience
When writing this book, I had two target audiences in mind. I
wanted to provide realworld WinForms coverage for both the
programmer that had already programmed in .NET as well as for the
programmer that hadn't. Towards that end, I do briefly introduce
core .NET topics as they come up. However, the .NET Framework
itself is a large area that this book doesn't pretend to cover
completely. Instead, when I think more information would be useful
to the reader, I reference another work that provides the full
details. In particular, I find that I've referenced Essential .NET,
by Don Box, with Chris Sells, a great deal, making it a good
companion to this book. In this same category, I can also recommend
Pragmatic ADO.NET, by Shawn Wildermuth, Advanced .NET Remoting, by
Ingo Rammer, .NET Web Services, by Keith Ballinger and Applied
Microsoft .NET Framework Programming, by Jeffrey Richter.
Two core .NET topics are of special importance to WinForms
programmers and I cover them in more detail in Appendix B:
Delegates & Events and Appendix C: Serialization Basics. The
coverage of delegates and events is particularly important if
you're new to .NET, although I don't recommend diving into that
topic until you've got a WinFormsspecific frame of reference (which
is provided about 1/3rd of the way through Chapter 1: Hello,
Windows Forms).
I'd like to provide one other note for potential readers. Many
years ago, I wrote my first fiveday training course. The topic was
Windows 95 and included a few hours of coverage on the new
controls; what they looked like, what their properties, methods and
events were and how to program against them. Those hours seemed to
take days for both me and for the students. The details of a
particular control are only interesting when you're putting that
control to use and when that time comes, the controlspecific
documentation and IntelliSense do a marvelous job of giving you the
information you need. Towards that end, this book covers none of
the standard controls completely. Instead, as each control is
interesting the context of the current topic, like the DataGrid
control in Chapter 13: Data Binding & Data Grids, that control
is covered appropriately. Also, Chapter 8: Controls and Chapter 9:
DesignTime Integration introduces the broad range of categories of
controls that WinForms provides, including the category of
nonvisual controls called components in .NET. Finally, to
give you a visual to go with all of the controls and components and
to introduce you to the major functionality of each of them,
Appendix D: Standard WinForms Components & Controls provides a
list of the standard controls and components. I wouldn't think to
waste your time by attempting to be more thorough that that
reference documentation that comes with the .NET Framework SDK and
Visual Studio .NET. Instead, this book focuses on the realworld
scenarios that aren't already covered in detail elsewhere.
Conventions
For those of you that have decided to take the plunge with this
book, I'd like to thank you for your faith and express my hope that
I live up to in. To aid you in reading the following text, I want
to let you in on some conventions I use in my writing.
First and foremost, the wonderful thing about WinForms is how
visual it is, which is why I use a lot of figures to illustrate its
features. Some of those pictures really need to be color to make
the point, so be sure to check the color pages at the center of
this book for those figures.
As useful as figures are, I think primarily in code. Code will
be shown in monofaced type:
System.Console.WriteLine("Hello, WinForms.");
Console application activation will also be shown in monofaced
type:
C:\> csc.exe hello.cs
When a part of a code snippet or a command line activation is of
particular interest, I mark it in bold and often provide a
comment:
// Notice the use of the .NET System
namespace
System.Console.WriteLine("Hello, WinForms.");
When I want to direct your attention to a piece of code even
more fully, I'll replace superfluous code with ellipses:
class MyForm : System.Windows.Forms.Form {
... // fields
private void MyForm_Load(object sender,
System.ComponentModel.EventArgs e) {
MessageBox.Show("Hello from MyForm");
}
}
Further, to make the printed code more readable, I'll often drop
namespaces and protection keywords when they don't provide
additional information:
// Shortened "System.Windows.Forms.Form" base
class
class MyForm : Form {
... // fields
// Removed "private" specifier and
"System.ComponentModel" namespace
void MyForm_Load(object sender, EventArgs e) {
MessageBox.Show("Hello from MyForm");
}
}
When showing .NET attributes, I use their full name:
SerializableAttribute
class MyCustomType {...}
Some languages, like C#, allow the "Attribute" suffix to be
dropped for convenience, but that makes it hard to find the details
of the attribute class in the online documentation.
Also, I sometimes take error checking out of the printed code
for clarity, but try to leave it in the sample code that comes with
this book.In the prose itself, I often put a word or phrase in
italics to indicate a new term that I'm about to define. As an
example of this kind of term and its definition, hegemony is
preponderant influence or authority, as well as a useful business
practice.
Finally, I often mention keyboard shortcuts because I find them
convenient. The ones I mention are the default Visual Studio
Developer key bindings. If you're not using those key bindings,
you'll need to map the keyboard shortcuts to your own settings.
Contact
The uptodate information for this book, including the source
code and the errata, are maintained at http://www.sellsbrothers.com/. This site also
provides a way for you to send feedback to me about the book, both
complimentary and less so.
0321116208P05022003