Responding to Object Changes in the User Interface

You have implemented business rules in your objects; now it is time to tell the users about the state of the objects they are accessing. Microsoft has provided a great new control called the ErrorProvider. The control is simple: It displays an icon (any icon you want) next to whatever control chooses to use it. You add the ErrorProvider control to the form level, and it is available to all of the controls on the form. In general, there are few good reasons to have more than one error provider on a single Windows form.

Tip

One reason to have more than one error provider on a Windows form is that you want to display different icons depending on the type of error or some other notification besides an error.

Implementing the ErrorProvider Control

To begin with, add an ErrorProvider control to your base edit form. Go to the frmEditBase form in design view. Double-click the ErrorProvider control in the Toolbox. Once you have done that, the form should look like Figure 5-7.

Figure 5-7: ErrorProvider on the frmEditBase form

Rename the control to erpMain. The ErrorProvider control has the properties shown in Table 5-4.

Table 5-4: The ErrorProvider Control Properties

Property	Description
BlinkRate	The rate at which the icon blinks (in milliseconds)
BlinkStyle	Has the following values: BlinkIfDifferent: If the error provider is not cleared and a new message is set, the icon will blink. AlwaysBlink: Icon always blinks. NeverBlink: Icon never blinks.
DataMember	The specific pieces of data to which the provider is bound
DataSource	The data source to which the control is bound
Icon	The icon that is displayed. The default icon is an exclamation mark.
Modifiers	Public, Protected, Friend, and Private

Alter any of the properties to suit your needs, but you must change the Modifiers property to Protected. This is so it can be accessed by all of your forms that inherit from the frmEditBase. Once you have done this, rebuild the solution so that your frmRegionEdit form reflects this change.

Displaying Errors to the User

Now let's edit the frmRegionEdit form so that you can take advantage of the self-aware object. Change the mobjRegion variable declaration so that it now handles events:

 Private WithEvents mobjRegion As Region 

Select mobjRegion from the Class Name drop-down list and select the BrokenRule event from the Method Name drop-down list. Modify the method that is created so that it looks like the method in Listing 5-11.

Listing 5-11: The BrokenRule Method Implemented

 Private Sub mobjRegion_BrokenRule(ByVal IsBroken As Boolean) _ Handles mobjRegion.BrokenRule      If IsBroken Then           btnOK.Enabled = False      Else           btnOK.Enabled = True      End If End Sub 

All you are doing here is checking to see if a rule is broken, and if it is, you disable the OK button; if there are no broken rules, you enable the OK button.

Caution

Some people use the absolute least amount of code necessary. For instance, the code in Listing 5-11 could be reduced to one line of code: btnOk.Enabled = Not IsBroken. But what if you need to take other actions that are dependant on the state of the object? In some cases, the least amount of code presents the most problems later.

Next you need to edit your Region Description textbox properties. When you select the txtRegionDescription textbox, there will be two new properties available to you in the Properties window. One property reads IconAlignment On erpMain (change this property value to MiddleLeft), and the other property reads, IconPadding on erpMain. The first property just selects where the icon will be displayed in relationship to the control, and the second property sets the padding around the icon. Set the icon alignment to the left side of the control if you like to see errors lined up uniformly as opposed to icons being displayed at the end of the control (which is the default). There is a third property associated with the error provider control, the Error property, which is displayed in the Properties window as Error on erpMain. Setting this property causes the error icon to be displayed. This is the property you will be setting in code to make the error icon appear next to your txtRegionDescription textbox.

Tip

The development team should use the same Integrated Development Environment (IDE) settings for the entire project. It is often good to test, with your projects settings, the placement of the error icon. Then you can devise a standard that says there must be X number of grid dots between the labels and the edit controls.

Now you need to edit the txtRegionDescription_Validate event so you can actually reflect the state of your object in the user interface. Modify the txtRegionDescription_Validate method so that it looks like the code in Listing 5-12.

Listing 5-12: The Modified txtRegionDescription_Validated Method

 Private Sub txtRegionDescription_Validated(ByVal sender As Object, _ ByVal e As System.EventArgs) Handles txtRegionDescription.Validated      Dim txt As TextBox = CType(sender, TextBox)      Try           mobjRegion.RegionDescription = txt.Text           erpmain.SetError(txt, "")      Catch exc As Exception           erpmain.SetError(txt, "")           erpmain.SetError(txt, exc.Message)      End Try End Sub 

The first line converts the sender object into a textbox object. Then you enclose the property Set method in a Try..Catch block because now, if the value is invalid, an exception will be thrown. If it is valid, you simply clear the error. If the value is invalid, then you first need to clear the error. The reason for this is that if there was an error before, and you set a new error, the error icon will still be displayed, but it will only display the original error. Then you set the new error.

Tip

Setting the error equal to an empty string clears the error icon.

The last thing you need to do is to disable the OK button if this form is opened as the result of the user clicking the Add button on the frmRegionList form. The reason for this is that your object is declared and instantiated in the frmRegionList form. Therefore, even though the object breaks its rules, the event is not reported to the edit form because the edit form has not been instantiated yet. And, when the user elects to add a record, they will start with an empty object that contains at least one broken rule, so it is invalid.

To do this, add the following line at the end of the constructor in the frmRegionList form:

 If Not mobjRegion.IsValid Then      btnOK.Enabled = False End If 

You are done! To test the results, run the application and do the following:

1. Select a Region from the Region List form and click Edit.

2. Delete the value in the Region Description textbox and tab out of the control.

3. You should see an error icon, and when you put your mouse over it, it should tell you that a value must be entered for this item and the OK button should be disabled.

4. Then, enter more than 50 characters in the Region Description textbox and tab out of the control.

5. You should see an error icon that tells you that the maximum length is 50 characters and the OK button is still disabled.

6. Enter a valid value and tab out of the text box.

7. The OK button should become enabled and you should be able to save the object.