Creating an Interactive Program

The editor does a good job of building simple GUI programs. However, a program isn’t interesting if the user can’t interact with it. The most interesting part of GUI programs is writing the code that responds to events. As usual, I’ll illustrate with a simple program.

Responding to a Simple Event

The silly program illustrated in Figures 6.13 and 6.14 illustrates how to add basic interactivity to your code. Again, most of the code is automatically generated for you, but you should know what is happening behind the scenes.

Figure 6.13: The temptation is almost irresistible.

Figure 6.14: When the user (inevitably) clicks the button, the program responds to the event.

Most of the interaction between the user and a GUI program happens as a result of some kind of event. The most common type of event you trap is the pressing of a button. However, almost every type of control you can place on a form has the capacity to send out events. Events are messages from an object. For example, during a long car trip, the Sister object might signal the HesTouchingMe event.

147

This event is a message that some other object (the Dad object, perhaps) might respond to (maybe by invoking the StopTheCar() method). Events are signals to other objects that something has happened. Most of the controls are capable of sending dozens of different types of events. When you write a GUI program, you have to inform the system which events of which controls you want to trap for. You must also specify what should be done if an event occurs. As you might expect, the Designer does much of this for you, but you should still know what’s going on.

Creating and Adding the Components

I designed this simple program by first imagining the form in my mind. (For more complex programs, I draw a sketch on paper or a chalkboard.) I then decided which tools from the Toolbox would best meet my needs. The label is an obvious choice for sending instructions and text (the Ouch!!! message) to the user. The button is also a good way to get input from the user.

In the Real World

Command buttons are part of graphical user interfaces purely for psychological reasons. They really are unnecessary from the programmer’s point of view because their main purpose is to be clicked and nearly every control supplied with .NET has the capacity to be clicked. Although a user might think that buttons are very important because they do things, a programmer knows that it’s actually the code that does the work, and the button’s job is to be a familiar metaphor. When users see a button, they know that something should happen when they click it. Although something might also happen when users click something else, it isn’t as obvious. Almost every form you make will have at least one command button on it. Never underestimate the power of psychology when it comes to designing your forms with components the user will understand intuitively.

Adding an Event to the Program

When you have a control to which you want to attach an event, you have two choices. You can double−click the component itself to get its default event, or you can choose from a list of other events. Most of the time, you will simply use the default event, because it is the most frequently called event of the component. For example, the most common event you trap for in a button is the click event, but in the form itself, you more often want to add code to the load event, which occurs as the form is loading into memory.

Most objects support several events, though, and double−clicking the control supplies only the most common event code. If you double−click a component in the Designer view, the editor automatically makes event−handling code for the default event of that component. If you want to use some other event of the control, change the Properties window so that it points to the events while your control is active in the Designer. Figure 6.15 shows the properties window displaying the events that are active. The Events tab on the Properties window looks like a lightening bolt. This tab is visible only when the Designer is visible on the screen.

148

Figure 6.15: Double−clicking any event automatically creates an event handler for that event. However you create an event, you are taken to a part of the code called an event handler. Event handlers are methods designed to occur when a specific event has been triggered. Here’s the event handler I got when I double−clicked btnDont:

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

}

Event handler names usually consist of the name of the object, an underscore (_) character, and the name of the event. All event handlers are automatically sent two parameters. The first is a sender object. This holds a reference to the object that sent the message. The second parameter is an EventArgs object. This special object is designed to hold other kinds of information about the event that just occurred. Generally, between the braces, you type the code you want to trigger. Here’s how I caused the label to say "Ouch!!!" when the button is clicked:

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

lblMessage.Text = "Ouch!!!";

}

I copied the string value "Ouch!!!" to the Text property of the lblMessage object. Most of the input and output in a GUI program involves moving values to and from properties of controls.

Creating an Event Handler

The code for the Don’t Click program was written almost entirely by the designer. Again, I want you to see this code in case you have to fix it.

The general code for creating this form is much like the Hello GUI program, so I won’t show you the entire thing. Of course, the names of the specific controls were changed, but only a few other things

149