Preface Windows 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? 1 AJAX stands for Asynchronous JavaScript and XML, as defined by Jesse James Garrett, "Ajax: A New Approach to Web Applications," http://www.adaptivepath.com/publications/essays/archives/000385.php (http://tinysells.

com/38). 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 2 At one point, the Component Object Model (COM) and ActiveX were made to work across platforms, but they have long since been relegated to Windows only. 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 3 WinFX (which inclues WPF) and Windows Vista are scheduled to ship in 2006. 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 more--even 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 .NET--and 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 topic--such as the DataGridView control in Chapter 17: Applied Data Binding--we 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.

Conventions If 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 { . //.