Windows Forms in Visual Studio .NET

Most WinForms projects start in the New Project dialog box, available via File New Project (Ctrl+Shift+N) and shown in Figure 1.1.

Figure 1.1. WinForms Projects

To build an application, you'll want the Windows Application project template. To build a library of custom controls or forms for reuse, you'll want the Windows Control Library project template. When you run the Windows Application Wizard, choosing whatever you like for the project name and location, you'll get a blank form in the Designer, as shown in Figure 1.2.

Figure 1.2. The WinForms Designer

Before we start the drag-and-drop extravaganza that the Designer enables, let's take a look at a slightly abbreviated version of the code generated by the WinForms application Wizard (available by right-clicking on the design surface and choosing View Code or by pressing F7):

 using System; using System.Windows.Forms; namespace MySecondApp {   public class Form1 : System.Windows.Forms.Form {     public Form1() {  InitializeComponent();  }  #region Windows Form Designer generated code   /// <summary>   /// Required method for Designer support - do not modify   /// the contents of this method with the code editor.   /// </summary>   private void InitializeComponent() {   this.Size = new System.Drawing.Size(300,300);   this.Text = "Form1";   }   #endregion  static void Main() {       Application.Run(new Form1());     }   } } 

Most of this code should be familiar, including the using statements at the top, the form class that derives from the Form base class, the static Main function inside a class providing the entry point to the application, and the call to Application.Run, passing an instance of the main form class. The only thing that's different from what we did ourselves is the call to InitializeComponent in the form's constructor to set the form's properties instead of doing it in the constructor itself. This is done so that the WinForms Designer, which we can use to design our form visually, has a place to put the code to initialize the form and the form's control. For example, dragging a button from the Toolbox onto the form's design surface will change the InitializeComponent implementation to look like this:

 private void InitializeComponent() {  this.button1 = new System.Windows.Forms.Button();   this.SuspendLayout();   //   // button1   //   this.button1.Location = new System.Drawing.Point(96, 72);   this.button1.Name = "button1";   this.button1.TabIndex = 0;   this.button1.Text = "button1";   //   // Form1   //   this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);   this.ClientSize = new System.Drawing.Size(292, 266);   this.Controls.AddRange(   new System.Windows.Forms.Control[] {   this.button1});   this.Name = "Form1";  this.Text = "Form1";  this.ResumeLayout(false);  } 

Notice again that this code is very similar to what we built ourselves, but this time created for us by the Designer. Unfortunately, for this process to work reliably, the Designer must have complete control over the InitializeComponent method. In fact, notice that the Wizard-generated InitializeComponent code is wrapped in a region, which will hide the code by default, and is marked with a telling comment:

 /// Required method for Designer support - do not modify /// the contents of this method with the code editor. 

It may look like your favorite programming language, but InitializeComponent is actually the serialized form of the object model that the Designer is using to manage the design surface. Although you can make minor changes to this code, such as changing the Text property on the new button, major changes are likely to be ignored ”or worse , thrown away. Feel free to experiment with just how far you can go by modifying this serialization format by hand, but don't be surprised when your work is lost. I recommend putting custom form initialization into the form's constructor, after the call to InitializeComponent, giving you confidence that your code will be safe from the Designer.

Of course, we put up with the transgression of the Designer because of the benefits it provides. For example, instead of writing lines of code to set properties on the form or the controls contained therein, all you have to do is to right-click on the object of interest and choose Properties (or press F4) to bring up the Property Browser for the selected object, as shown in Figure 1.3.

Figure 1.3. The Property Browser

Any properties with nondefault values, as indicated by values in boldface in the browser, will be written into the InitializeComponent method for you. Similarly, to choose an event to handle for the form or the form's controls, you can press the Events lighting bolt at the top of the Property Browser window to open the list shown in Figure 1.4.

Figure 1.4. List of Events

You have a few ways to handle an event from the Property Browser window. One way is to find the event you'd like to handle on the object selected (say, Click) and type the name of the function you'd like to call when this event is fired (say, button_Click). Then press Enter, and VS.NET will take you to the body of an event handler with that name and the correct signature, all ready for you to implement:

 private void button_Click(object sender, System.EventArgs e) { } 

After you've added a handler to a form, that handler will show up in a drop-down list for other events having the same signature. This technique is handy if you'd like the same event for multiple objects to be handled by the same method, such as multiple buttons with the same handler. You can use the sender argument to determine which object fired the event:

 private void button_Click(object sender, System.EventArgs e) {   Button button = sender as Button;   MessageBox.Show(button.Text + " was clicked"); } 

If, as is often the case, you'd like each event that you handle for each object to be unique or you just don't care what the name of the handler is, you can simply double-click on the name of the event in the Property Browser; an event handler name will be generated for you, based on the name of the control and the name of the event. For example, if you double-clicked on the Load event for the Form1 form, the event handler name would be Form1_Load.

Furthermore, if you're handling the default event of an object, you can handle it simply by double-clicking on the object itself. This will generate an event handler name just as if you'd double-clicked on that event name in the Property Browser event list. The default event of an object is meant to be intuitively the most handled event for a particular type. For example, I'm sure you won't be surprised to learn that the default event for a button is Click and that the default event for a Form is Load. Unfortunately, neither the Designer nor the Property Browser gives any indication what the default event will be for a particular type, but experimentation should reveal few surprises .