Advanced Visual Basic Techniques
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471188816
Publication Date: 06/01/97

View/Controllers

In many programs the distinction between views and controllers blurs. In AppointmentBook the month area acts as a view when it displays a calendar showing which dates contain appointments. It acts as a controller when the user clicks on it to select a new date. The month area acts as both a view and a controller.

View/controllers often arise from the direct-manipulation nature of Windows programs. The month area allows a user to view and manipulate the data so it is both a view and a controller. Many other Visual Basic controls work similarly. Text boxes, option buttons, check boxes, combo boxes, scroll bars, lists, and others can all be used both to display and manipulate information. When a class is tied closely to one of these controls, chances are good the class will be both a view and a controller.

When working with a view/controller class, a program should keep the view and controller functions as separate as possible. Programs that use one routine to play the roles of both view and controller can be very confusing.

In particular, whenever possible the program should not make controller routines update the view’s display. Instead, the model should tell the view/controller, acting as a view, to update itself. For example, when the user clicks on AppointmentBook’s month area, the area must select a new date and update its display to show the new date. Rather than performing both of these actions in the single subroutine, the CalVC class uses the model’s subroutines only to set the new date. The model then notifies the view of the change so it can update its display.

This technique does not work with Visual Basic controls that automatically update their own appearances. For instance, suppose a program has a view/controller object that manages a text box. Then suppose program code changes the value of the text. This generates a Changed event for the text box. Acting as a controller, the object detects the change and updates the model. The model then notifies the object that a change to the text has occurred. Now acting as a view, the object updates the text box. This generates another Changed event, which causes the object to act as a controller again and notify the model of the change. This causes another event notification, which causes a text update, which causes yet another event notification, and so forth.

In cases such as this one, the program needs a way to break out of the infinite cascade of changes and event notifications. AppointmentBook’s view/controller objects do this with a Boolean variable IgnoreChanges. Just before the object (acting as a view) modifies the display, it sets IgnoreChanges to true. When the object detects a change, it checks the value of IgnoreChanges. If the value is true, it ignores the change. Otherwise, it reports the change (acting as a controller) to the model. After the object (acting as a view) finishes modifying the display, it sets IgnoreChanges back to false so changes made by the user are reported to the model in the future.

The following code fragment shows how AppointmentBook prevents event cascades for the month area’s scroll bar:

Private IgnoreChanges As Boolean
    :
‘ The model is notifying us that the selected date has changed.
Public Sub Notify(event_mask As Long)
    :
    ‘ Verify that the selected date has changed.
    If event_mask And CAL_SelectedDateChanged Then
        IgnoreChanges = True    ‘ Prevent an event cascade.

        ‘ Change the scroll bar value to reflect the new date.
        TheScrollBar.Value = _
            DateDiff(“ww”, TheModel.FirstDate, _
                TheModel.SelectedDate)

        IgnoreChanges = False   ‘ Report future events to the model.
    End If
End Sub

‘ Someone (the user or the program) has changed the scroll bar value.
Public Sub ValueChanged(Value As Integer)
    ‘ If IgnoreChanges is true, the program made the change.
    ‘ Do not start an event cascade.
    If IgnoreChanges Then Exit Sub

    ‘ The user made the change. Tell the model about it.
    TheModel.SelectedWeek = Value
End Sub

MVC in AppointmentBook

This section lists the data events used by AppointmentBook. It then explains the duties of the application’s model, views, and controllers. This section focuses mainly on how the objects interact using the MVC paradigm. It does not describe class details such as how the CalVC object draws the month area. Although these implementation details require quite a bit of Visual Basic code, they are relatively straightforward and are not important for the discussion of the more advanced topic of MVC. You can see all of the code on the compact disk.

To make it a bit easier to remember the purposes of the classes, the names of view classes end with the letter V, the names of controller classes end with a C, and view/controller classes have names ending with VC.

Events AppointmentBook defines the following data events in the module CalStuff.BAS:

•  CAL_AllEvents. This bit mask has every bit set. It is used mainly when the data file is first loaded. By passing this event to the NotifyViews subroutine, the model ensures that every registered view updates its display.

•  CAL_TopDateChanged. The topmost visible date in the month area has changed. This may have happened because the user adjusted the month area’s scroll bar, pressed an arrow key, or invoked the Select Today command in the Appointments menu.

•  CAL_SelectedDateChanged. The selected date changed. This will happen when the user clicks on a date in the month area. It is also generated in the same ways as CAL_TopDateChanged: scrolling the month area, pressing an arrow key, or invoking Select Today.

•  CAL_TemporaryDateChanged. The temporary date changed. While the user is dragging the month area’s scroll bar slider, this date is the date that would be selected if the user released the slider. Dragging the slider is the only way to generate this event.

•  CAL_YearsChanged. The years represented by the data have changed. This happens only when the data file is first loaded.

•  CAL_Resized. The month area has changed size. This occurs when the user resizes the form.

•  CAL_AppointmentChanged. One of the selected date’s appointments has been modified.

•  CAL_DailyApptDeleted. The user deleted the last appointment for some date other than the selected date. This occurs when the user invokes the Purge command in the Appointments menu.

•  CAL_UserWasWarned. The program presented a message warning the user that it was almost time for an appointment.