Preface
PrefaceWindows 1.0 programmers had a straightforward life. They had almost no choices about how to do things; either there was an application programming interface (API), or there wasn't, and most of the time there wasn't. This meant that developers had to build almost everything by hand. At the time, this wasn't a problem. All Windows programmers had the same limitations, so everyone's apps more or less operated with the same limited set of functionality. A modern Windows developer, on the other hand, is inundated with choices. The invention of the web alone gives us static Hypertext Markup Language (HTML), server-based user interface (UI) interaction via ASP.NET, and client-side UI interaction via ActiveX controls or AJAX (to name a few).[1] On the client side, we have native frameworks like Microsoft Foundation Classes (MFC), Active Template Library (ATL), and the next-generation managed framework known as the Windows Presentation Foundation (WPF is part of WinFX, the follow-on to the .NET Framework). How does a developer choose? Where does Windows Forms 2.0, the topic of this book, fit into this pantheon?
Client technologies on Windows provide a range of reach and richness in inverse proportion to each other. Reach is the ability of a user interface (UI) to work across operating systems, whereas richness is the ability for a UI to take advantage of the operating system on which it runs. So even though static HTML works almost everywhere, to the extent that your HTML uses client-side JScript, reach is diminished for browsers that don't support the scripting constructs being used. Even further down the reach scale are ActiveX controls, which work only on Windows but allow full access to its richness.[2]
At the other extreme we have WPF, a completely new managed framework built on top of DirectX. WPF encompasses documents, layout, animation, 2-D, 3-D, text, and graphics primitives in a single, cohesive whole. This framework provides the richest client technology that Microsoft has ever built, and it takes maximum advantage of the platform on which it runs, including any hardware 3-D graphics acceleration that may be available. However, at the time of this writing, WPF has not yet shipped and works only under Windows XP, Windows Server 2003, and Windows Vista.[3]
Where does that leave Windows Forms 2.0? It doesn't quite offer the richness of WPF, but it's far richer than the HTML-based technologies. Windows Forms 2.0 also is much richer than Windows Forms 1.0, with greatly enhanced support for flexible layout, modern menu strip and tool strip controls, data binding, multithreading, typed resources and settings, and, most importantly, ClickOnce deployment. With ClickOnce, for the first time, users can deploy Windows applications as easily as web applications. Even better, ClickOnce allows Windows applications to be installed locally, integrated with the Start menu, and accessed even if no network connection is available. These options are not available for users of Web applications. So Windows Forms 2.0 is high on the richness scale, but what about the reach scale? Unlike web applications, Windows Forms requires that users' machines operate on Windows, specifically Windows 98 or later for PCs. However, it also supports other devices, such as Pocket PCs or Smartphones, via the .NET Compact Framework. This means that you can write a Windows Forms 2.0 application and run it on your Windows smartphone. Based on this level of richness and reach, what kinds of applications should you build with Windows Forms? As it turns out, folks have used Windows Forms to build almost every kind of application, including productivity applications, utilities, enterprise tools, and moreeven games. Windows Forms can be used to build smaller things, such as Microsoft's own internal human resources application (called HeadTrax), or larger things, such as most of the UI enhancements that have been built on top of Visual Studio since the 2002 edition. This range of applications can be built because of Windows Forms' range of features and tools, its reach, and, as of this version, the maturity of the implementation based on community usage and feedback. In fact, the .NET developer community has embraced Windows Forms to a degree that defies the early .NET focus on web-based applications. Based on talking to my friends in the training industry and on the sales of the first edition of this book, I conclude that a large and growing number of developers write Windows Forms applications. It's for those developers that we've written this book. Who Should Read This Book?When writing this book, we wanted to provide real-world Windows Forms coverage for programmers who've programmed in .NETand those who haven't. To that end, we briefly introduce core .NET topics as they come up. However, we don't pretend to cover the .NET Framework completely. It's too large a topic. Instead, when we think more information would be useful, we reference another work that provides the full details. In particular, you'll find that we've referenced Essential .NET, by Don Box, with Chris Sells, a great deal, making it a good companion to this book. In the same category, we also recommend Advanced .NET Remoting, by Ingo Rammer, and Applied Microsoft .NET Framework Programming, by Jeffrey Richter. (For more details on these books, see the Bibliography.) One core .NET topic is of special importance to Windows Forms programmers, and we cover it in more detail in Appendix C: Delegates and Events. This coverage is particularly important if you're new to .NET, although we don't recommend diving into that topic until you've got a Windows Forms-specific frame of reference (which is provided about one-third of the way through Chapter 1: Hello, Windows Forms). Also of particular importance to former (or soon-to-be former) MFC programmers, we've provided Appendix B: Moving from MFC, and Appendix F: Document Management. Although Windows Forms doesn't provide all the features of MFC, we've worked hard on the material and code samples in this book to plug most of the gaps. One other note: Many years ago, one of the authors wrote his first five-day training course. The topic, Windows 95, 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 like days for everyone involved. The details of a particular control are interesting only when you're putting it to use, and when that time comes, the control-specific documentation and Visual Studio's IntelliSense help support do a marvelous job of giving you the information you need. To that end, this book covers none of the standard controls completely. Instead, when a control is interesting in the context of the current topicsuch as the DataGridView control in Chapter 17: Applied Data Bindingwe cover that control appropriately. Also, to give you a list of all the components and controls and to introduce you to each one's major functionality, Appendix D: Component and Control Survey provides a list of the standard controls and components. We wouldn't think of wasting your time by attempting to be more thorough than the reference documentation that comes with the .NET Framework software development kit (SDK) and Visual Studio 2005. Instead, this book focuses on the real-world scenarios that aren't covered in detail elsewhere. Finally, to help you understand the differences between components and controls and how to build both, we've provided Chapter 9: Components and Chapter 10: Controls. ConventionsIf you've decided to take the plunge with this book, we'd like to thank you for your faith and express our hope that we live up to it. To aid you in reading the text, we want to let you in on some conventions we use. First, there is the mode of address that we use throughout the book (except for this preface). Because Chris and Michael worked so closely and so hard on every word in this book, the use of "I" really means "both authors," whereas the use of "we" means "the authors and you." Although we sometimes use "you" directly, Michael and Chris lean toward the inclusive. The wonderful thing about Windows Forms is how visual it is, and that's why we use a lot of figures to illustrate its features. Some of those pictures really need to be in color to make the point, so be sure to check the color pages at the center of this book for those color plates. As useful as figures are, we both think primarily in code. Code is shown in monospace type: System.Console.WriteLine("Hello, Windows Forms.");Console application activation is also shown in monospace type: C:\> csc.exe hello.cs When a part of a code snippet or a command line activation is of particular interest, we mark it in bold and often provide a comment: // Notice the use of the .NET System namespace System.Console.WriteLine("Hello, Windows Forms.");When we want to direct your attention to a piece of code more fully, we 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"); } }Furthermore, to make the printed code more readable, we 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, we use their abbreviated name: [Serializable] // Instead of [SerializableAttribute] class MyCustomType {...}C# lets you drop the "Attribute" suffix for convenience, but remember to append this suffix when you look up the details of the attribute class in the online documentation. For clarity, we sometimes omit error checking from the printed code, but we try to leave it in the sample code that you'll find at our web site. In the text, we often put a word or phrase in italics to indicate a new term that we're about to define. As an example of this kind of term and its definition, hegemony is a preponderant influence or authority, as well as a potent business practice. Sometimes, we mention keyboard shortcuts because we find them convenient. The ones I mention are the default Visual Studio 2005 (VS05) key bindings for C# programmers. If you're not using those key bindings, you'll need to map the keyboard shortcuts to your own settings. Finally, because this is the second edition of this book, we've taken care to mark new and updated types in the margins with graphics and in the code with comments. Also, for a summary of what's new in Windows Forms, check out Appendix A: What's New in Windows Forms 2.0. ContactThe up-to-date information for this book, including the source code and the errata, are maintained at http://www.sellsbrothers.com/writing/wfbook. This site also lets you send feedback about the book, both complimentary and less so. Michael's AcknowledgmentsWriting a book is not just the application of pen to paper, nor is its creation confined to the authors. Whether they know it or not, many people have helped make this book what it is. My parents, Josef and Lili: Without a doubt, I could not have seen this book through to the end if it weren't for the immeasurable and unquestioning love and support of my parents. They've been there for me in this way since the day I was born, which I find truly staggering. How can I thank them enough? I simply cannot. Instead, I try and do the best I can by making the most out of the life they've provided. For this reason, I put everything I had into this book. My brother, Alex: When he applied to attend a university, he definitely met the entry requirements. However, he was told by the university that he shouldn't bother because it would be very unlikely he would complete his studies successfully. Of course, they were very wrong. When I endure some of the darker moments in writing and want to throw it all away, I think of all he has accomplished in his life. Then I very quickly realize that writing so completely pales in comparison, before pulling my head in and keeping on writing. He is a big inspiration in my life, and he helped me to stay the course on this book. I thought he should know. My coauthor, Chris Sells: I have often written with Chris because I enjoy it so much. It's fun, it's a challenge, and it usually results in the production of something that I can really be proud of. When Chris asked me to coauthor this book, I couldn't say no. I'm still surprised by how much latitude he gave me to work with, more than a one-to-one update of the first edition, and I can't thank him enough for his faith, and for all that he has given over the years. My friends Kym Phillpotts and Hodaka Shibata: They've been there for me for the long haul, and when I think of good mates, I instantly think of them. "Mr. Windows Forms," Mark Boulter: Even though I've never met Mark in the physical world, he has played a huge role in fueling my passion for Windows Forms and the desire to tell its story. I'd always hoped that he would write the foreword for this book, and I am honored he did. My safety net, Microsoft's Jessica Fosler: When I had technical and conceptual questions that often needed quick responses, Jessica always provided articulate, comprehensive, and prompt answers, for which I am very grateful. And, as if that weren't enough, Jessica made time to review our entire book, provide thorough and positive commentary, and, for good measure, threw in some great prose. Our main reviewer, Christophe Nasarre: Christophe performed two reviews in a very limited time. It is almost scary how good he is and how much the book improved as a result of his efforts. I can honestly say that I felt comfortable about this book only after his involvement, and if I ever write another book, I'll be disappointed if he isn't available. Merci! Our Microsoft reviewers, Sameer Bhangar, Barry Briggs, Felix Cheung, Andrew Coates, Jamie Cool, Shreeman Dash, Erick Ellis, Shawn Farkas, David Guyer, Mike Harsh, Zach Kramer, Steve Lasker, Elizabeth Maher, Chris Meyer, Mark Rideout, and Joe Stegman: All had a role in the development of Windows Forms 2.0, so it was a little nerve racking letting them review our exposition of their work. However, it was also vital because they provided extremely comprehensive technical and conceptual commentary that dramatically improved the quality of the end result. Our user reviewers, William Bartholomew, Ron Green, Kym Phillpotts, and Fumiaki Yoshimatsu: No technology book can be released without reviews from people who will actually use the technology and will lean on our book to learn about it. From this perspective, these guys provided valuable insight that nicely juxtaposed the more technical focus provided by the Microsofties. Betsy Hardinger, Grammar Guru Extraordinaire: Betsy, as Chris likes to call her, is a grammar geek. She loves what she does. She's incredible at what she does. She's funny. She puts Strunk and White to shame. And, last but not least, Addison-Wesley: This is my first experience with a technical book publisher, and it was a great one. The editors pretty much let us tell the story the way we wanted, always making sure we had what we needed and never pressuring us. Thanks! Chris's AcknowledgmentsAlthough this book is dedicated to my family, I'd also like to acknowledge them here. I work from my home, and in completing the book I often had to spend a great deal of extra time to get the thing out the door. My wife, Melissa, is always enormously understanding when I have a deadline and gives me the space I need to meet it. Also, I tend to leave my office door open because I like my family, and often my boys, John and Tom, will come in to talk to me about their day. Even though they're only eleven and ten, respectively, they're uncharacteristically understanding when it comes to letting me focus on my work for "just another five minutes" (although woe is me if I overpromise and underdeliver to those two, I'll tell you). Although my family gave me the space to write, this book would not be what it is without the efforts of my coauthor. Michael dedicated most of two years to this book. Michael's job was primarily to update the chapters based on the additions and changes in Windows Forms 2.0, but he did far more than that. His efforts in re-evaluating each and every part of the story and his willingness to try new ways to present information produced a far better book than the first edition. You should keep an eye out for Michael's future writings. He's definitely one of the good ones. I also need to give special thanks to Mark Boulter for having a positive influence both on the Windows Forms technology and on my understanding of it, and also for writing our foreword. He doesn't consider himself a writer, so I literally had to call him and beg for his participation after he told me "no," but I couldn't imagine anyone else I'd want to do it. Special attention needs to be paid to any book's reviewers. Without the reviewers, authors might think that when they've written prose that covers a topic, they're actually finished. Oh, hated reviews, which correct this assumption, and sweet reviewers, who make sure our readers aren't tortured with inaccurate or unreadable prose and uncompiling code. Our grand inquisitor was Christophe Nasarre, who flayed us so thoroughly in our first round of reviews that we asked him to be the sole reviewer in the second round. Christophe is such a wonderful reviewer that he's always busy with reviews, but he was able to squeeze us into an extremely short period while still finding things I'm embarrassed to have written in the first place. Thanks, Christophe! This book is immeasurably better because of your efforts. We also had a dedicated team of reviewers from outside Microsoft, including Ryan Dorrell, Kym Phillpotts, Fumiaki Yoshimatsu, Ron Green, and William Bartholomew. External reviewers are particularly important because they're not steeped in the internal history of Windows Forms, and they represent our target audience. Thanks, guys! On the other hand, this book represents not only Mike's and my work with Windows Forms, but also a large number of Microsoft employees who took the time to review our chapters in their areas of expertise and make sure we weren't missing the important things. This group includes Joe Stegman, Steve Lasker, Andrew Coates, Chris Meyer, Elizabeth Maher, David Guyer, Jessica Fosler, Sameer Bhangar, Felix Cheung, Mark Rideout, Shreeman Dash, Shawn Farkas, Erick Ellis, Mike Harsh, Jamie Cool, Zach Kramer, and Barry Briggs. Of special note are Steve Lasker, who gave us especially deep feedback on the data binding chapters on very short notice, and Jessica Fosler, who was our final authority on a huge range of topics. Michael and I tried very hard to make sure that we didn't slaughter the story of your technology; thanks for all the details we couldn't have found any other way. I'd like to thank MSDN Magazine, MSDN Online, and Windows Developer magazine for allowing us to reuse material from articles that they originally published (as listed in the Bibliography). I'd also like to thank the readers of the first edition of this book, whose feedback on the initial pieces and the first edition helped shape the final version of this content, as well as inspired me to dig ever deeper. Last but not least, I'd like to thank the fine folks at Addison-Wesley. In increasingly tight times, they still manage to provide me an environment where I can write what I think best. Special thanks go to Betsy Hardinger: copy editor, frustrated fiction author, kindred spirit, and hyphen mentor. In addition to turning my prose into English, she also managed to catch technical inconsistencies that hard-core developers missed. Thanks, Betsy! These folks, along with a bunch I'm sure I've missed, have helped shape everything good that comes through in this book. The errors that remain are our own. Chris Sells sellsbrothers.com Michael Weinhardt mikedub.net |
EAN: 2147483647
Pages: 216