Beginning Visual Basic 2005 Express Edition - From Novice To Professional (2006)

The first parameter passed to any event handler is called sender and it’s typed as

an object. This is actually the control that fired the event. By casting it to the appropriate object type, you can interact with it just as you would any other control. Notice also how Button1_Click actually specifies at the end of the subroutine definition Handles Button1.Click. This is the connection among a control and an event and your code. If you used the event browser to link one event handler to more than one control, that Handles statement would be expanded to a list of controls, like this:

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click, _

Button2.Click, Button4.Click, Button3.Click

End Sub

Common Properties and Events

Every single control that you drop onto a form to build your application’s user interface is a subclass of System.Windows.Forms.Control. What this means to you, of course, is that every visual control you’ll ever use will inherit a common set of functions, properties, and events from that base System.Windows.Forms.Control. If you take a look at the online help for System.Windows.Forms.Control, you’ll see that the list is in fact huge, but the good news is that you don’t need to memorize everything there.

On the properties side, the most common properties that you’ll want to work with are listed in Table 8-1.

Table 8-1. The Most Common Properties You’ll Ever Work With

Of course, there are other common properties, but these are by far the most useful and frequently used.

Similarly, there is a huge list of events that every control can generate. For example, all visual controls in .NET can fire off a Click event in response to the user clicking them with the mouse, and also Validating and Validated events to let you check the contents of the control after the user has finished messing with them. Rather than listing them all here, I’ll have you look at the events as you explore each of the controls throughout the rest of this chapter and the rest of the book.

Buttons in All Their Glory

I’d like to introduce you to perhaps the simplest, and most common, of all the controls in the Toolbox—the humble Button control. The button, while sporting a wealth of properties that let you change its general appearance, is really designed to do just one thing: click. In fact, it does a little more than that. It can be depressed, and it can pop up after being depressed—if only life were as simple. If you really wanted to take the button to the very bleeding edge, you could even get it to do things when the mouse travels over it, when it’s dragged, or when things are dropped on it. See, not so simple a control after all, is it.

Let’s take a look.

Try It Out: Working with Buttons

Start up a new Windows project. When the form editor appears, drop a button onto the form’s surface, as in Figure 8-2.

Figure 8-2. Drop a button onto the form, like this.

Select the button by clicking it just once, and if the Properties window is not currently visible, press F4 on the keyboard (or select Properties Window from the View menu) to bring it into view.

Notice at the top of the Properties window there is a button that looks quite like a lightning bolt. Click this, and the Properties window will change to show you a list of all the events that the button can respond to. You can see this in Figure 8-3.

Figure 8-3. The Properties window also shows you the list of all the events that a control supports.

Events, as I explained earlier, are raised by controls, more often than not as a result of the user doing something. There are a few events in the list, though, that have very little to do with the user. The Paint event is a good example. This event fires whenever the button needs to redraw itself—for example, when it reappears after being covered by another window.

Let’s take a look at some of the events in action. Scroll down the list of events and find the MouseEnter event.

Double-click in the entry area to the right of the event name (MouseEnter), and your code window will appear, looking like mine in Figure 8-4.

Figure 8-4. Double-clicking the event in the event list drops you into the code editor for that event.

Add some code to the event so that it reads like this:

Private Sub Button1_MouseEnter(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.MouseEnter

Button1.Text = "The mouse is over me"

End Sub

What you’re saying here is that when the mouse enters the control, you’ll change the Text in the control.

Go back to the form editor by clicking its tab at the top of the code window, and reselect the button. This time find the MouseLeave event in the event list and click it once. Notice the drop-down button in the entry area next to the event name (see Figure 8-5).

Figure 8-5. The event drop-down lets you set up one method to work with many different events.

Clicking the drop-down button shows you a list of event handlers you’ve already written that could be used for this event as well. These aren’t necessarily event handlers for just the currently selected control; if you had a few buttons on the form, you could have them all use the same event handler.

For now, though, just double-click in the entry area beside the event name (MouseLeave) to go into the editor for that event. Change the code so that it looks like mine here:

Private Sub Button1_MouseLeave(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.MouseLeave

Button1.Text = "The mouse is not over me"

End Sub

Run the application and wave the mouse over the button—the caption will change as the button’s events fire.

Stop the program that is running by closing down the window in the usual way when you are finished exploring.

Every control has a default event that logically fits the control. With a button, for example, the default event is Click. Double-click the button on the form editor and you’ll see the code window open up, ready for you to fill in the button’s Click event.

I mentioned earlier that an event could be called by many controls. But the problem is that so far the code you’ve written pretty much assumes which control triggered it (you explicitly set Button1’s Text property). This is exactly where the two parameters passed to the event come into play:

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

End Sub

The first parameter, sender, can be used to figure out which control sent the event through. Let’s add some code to the click event handler to demonstrate this:

Private Sub Button1_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles Button1.Click

Dim clickedButton As Button = TryCast(sender, Button) If Not clickedButton Is Nothing Then

clickedButton.Text = "I was clicked" End If

End Sub

I’ll walk through the code just in case some of it doesn’t make sense. First, a new object variable is created to hold a button. On the same line of code, a new Visual Basic command called TryCast is used. Before Visual Basic 2005, if you wanted to convert an object (such as sender) into another type of object (such as Button), you’d use a command called CType. The problem is, if sender is not actually a Button, you end getting a runtime exception, meaning that you’d have to write exception handlers into the code. In addition, dealing with exceptions takes quite some time at runtime, and we want our application to remain quite “snappy.” TryCast solves this problem. It attempts to convert one object into another type. If the conversion is successful, the result is the converted object. On the other hand, if the conversion can’t be performed, the result is a special Visual Basic data type called Nothing.

The very next line of code checks to see whether your object is Nothing. Assuming it’s not, clickedButton’s Text property is set to I was clicked. In English, if the sender of the event is a button, you set its Text property. Go ahead and run the application to try this out (see Figure 8-6). Notice of course that adding a click handler doesn’t in any way affect the MouseEnter and MouseLeave events you already coded.

button, text boxes provide a great deal of functionality beneath the surface, and a mass of events they can respond to. The most interesting of these are listed in Table 8-2.

Table 8-2. The Most Useful Events of a Text Box

In terms of functionality, the humble text box packs a whole lot in. You can type on the keyboard to enter text, and the control automatically supports backspacing, deleting, and navigating around the text with the keyboard cursor keys. You can cut and paste by using the Windows Clipboard without having to write any special code. You can also select part or all of the text and have the text box automatically highlight the selected text. In fact, out of the box without any effort on your part, the text box works just the way users would expect a text box in any other Windows application to work. Aren’t user interface standards great!

All this functionality brings with it some interesting properties that you haven’t really seen yet. Table 8-3 lists some of the most important.

Table 8-3. Some of the More Interesting Properties Attached to a Text Box