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

Figure 8-16. The MaskedTextBox control comes with a number of masks built in.

As you select masks in the list, notice how the Mask and Preview text boxes at the bottom of the dialog box change. The Mask text box shows you the actual value that will be fed into the Mask property of the MaskedTextBox, while the Preview text box shows you what the MaskedTextBox will look like to a user of your application. The underline characters that appear when you click on a format show where the user needs to enter data. Any other characters are inserted automatically.

If you take a look at the masks list, you’ll also notice a third column called Validating Type. In addition to forcing users to meet a certain mask when they enter data, the control can also check that the resulting data will fit into a specific type. For example, you could select a mask that defines just how to enter a date, but there’s still a risk that a user would put the day and month of the date in the wrong order. In that case, using a validating type of System.DateTime will ensure that the data entered not only is in the right format but also is a valid DateTime value. The data type shown here is entered into the ValidatingType property of the MaskedTextBox, a property that you can access only from within your code (it’s not shown in the Properties window).

You don’t have to use a ValidatingType, though. Just like a standard TextBox control, the MaskedTextBox control uses the Validated and Validating events to let you programmatically check that the value entered by the user not only conforms to the correct visual format but also contains a valid value.

Adding a ToolTip control to a form merely makes it possible to show ToolTips. It doesn’t actually set up, display, or hold the tips themselves. Now that you have that control on the form, though, click on one of the text boxes and take a look at the Properties window. You’ll see a new property called ToolTip On ToolTip1. This is the ToolTip that you want displayed when the ToolTip control is enabled and the mouse is over the control. You could have more than one ToolTip control on a form and enable them or disable them at runtime by setting their Enabled properties to True or False. In that way, you could display different kinds of tips based on the user (from novice to expert, for example).

Put something into this property and set up the ToolTip On ToolTip1 properties on some of the other controls. Then run your program.

At runtime you’ll find that if you move the mouse over a control that has a ToolTip set and let it hover there for a while, a ToolTip will pop up (see Figure 8-18).

Figure 8-18. With a ToolTip control on the form and enabled, ToolTips associated with controls can be displayed at runtime. It’s automatic.

Try It Out: Adding an ErrorProvider

The validation example from earlier in the chapter puts up a message box when validation fails. This is a pretty neat visual way for an author to get your attention with some sample code in a book, but it’s not very elegant from a user interface perspective; suddenly the user needs to stop what she is doing and focus her attention on a new window that’s just appeared. It will also become really tedious if you have a complex form with a few dozen input areas that all need validation.

.NET provides a wonderful little control called an ErrorProvider that can help you out. The ErrorProvider exists solely to display icons and error messages for controls with problems. Load up the code you were just working on and then find the ErrorProvider control in the Toolbox. You can see what it looks like in Figure 8-19.

Figure 8-19. The ErrorProvider gives you a wonderful way to draw a user’s attention to problems on a page.

You really should bear the ErrorProvider in mind when writing your own applications. It’s a much better way of providing feedback to users than the somewhat jarring standard of throwing a message box up on-screen for each and every error.

Choosing Things: Radio Buttons and Check Boxes

I’m sure you’ve seen option dialog boxes in Windows programs that ask you choose to turn certain things on or off, or to select one from a handful of options. Take a look at the Options dialog box from Microsoft Word in Figure 8-21 to see what I mean.

Figure 8-21. Lots of applications use controls that limit the number of possible things the user can choose.

Aside from lists and drop-down lists, which I’ll cover later in this book, the two most common types of control you’ll use for this are the RadioButton and the CheckBox. You can see these in Figure 8-22.

Figure 8-22. The RadioButton and CheckBox controls limit the number of possible things a user can do or choose.

Although they look similar, the two controls work in very different ways. The check box (that’s the square one) simply forces the user to choose one of two things. Think of it as a switch; it could be on or off, black or white, yes or no, male or female—you get the idea.

The radio button, on the other hand, is mutually exclusive. What that means is that you can select only one radio button from a group. You would use this when you want the user to choose from a very small number of possible things. I recently came across a good example of this on a flight-booking website. Radio buttons were used to force the user to choose the class of ticket: Economy, Business, or First.

There is a catch, though, with radio buttons (isn’t there always): they are mutually exclusive within their container. Take a look at Figure 8-23.

Figure 8-23. Radio buttons are mutually exclusive within their container.

Figure 8-23 shows two sets of radio buttons in two different containers. The first set is placed directly on the form, so selecting any of them will instantly deselect any other in that group.

The second set is contained within a group box and works the same way. This means that even though there are six radio buttons in total, they are split into two groups of three, and the user would be free to choose two at once: one from the first group, and one from the second. Go ahead and build this form in VB Express and then run the program to see what I mean.

So, radio buttons and check boxes look similar but work in different ways. At a code level, though, they work the same way, exposing the same events and properties to work with them. At an event level, there really is just one event that you’ll be most interested in working with: the CheckedChanged event. It does exactly what it says, firing whenever the user clicks in a control to check or uncheck it.

In terms of properties, the controls support all the standard ones for appearance (Font, Text and so on), but also expose a Checked property. This is a Boolean (True/False) property. If the control is currently checked (selected), the property is True. If it’s False, the control isn’t checked.

Let’s take a look at an example and focus on the RadioButton control.

Try It Out: Radio Buttons

You’re going to produce a small form here for a fictitious flight-booking system. The form itself is the window the user will see when asked to confirm the class of ticket required, so you need to write code to figure what the user chose. You’ll do it the hard way first.

Start up a new Windows project. Then resize the form in the project and drop some radio buttons and a command button onto it so it looks like mine in Figure 8-24.

Figure 8-24. Arrange controls on your application’s form so it looks like this.

You can tell from the screen shot just what the Text properties of all the controls should be. Set the Name of the command button to okButton, and then set the names of the radio buttons to economyRadio, premiumRadio, businessRadio, upperRadio, and firstRadio.

With that out of the way, you can start coding. What I’d like to happen is that when the OK button is clicked, a message box appears confirming the class of ticket the user just selected. As I said a little while ago, you’ll do this the hard way first. That way, when I show you an alternate method shortly, you’ll appreciate it all the more.