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

Bit Masks in AppointmentBook

AppointmentBook uses bit masks to track events using the model/view/controller (MVC) paradigm. MVC is described in detail in the following section, “Using the MVC Paradigm,” but its use of bit masks is described here.

AppointmentBook uses bit masks to define certain events. For example, when the user clicks on a new date in the month area, the application selects that date. The program associates this event with an event mask defined by the following code:

Public Const CAL_SelectedDateChanged = &H2

AppointmentBook keeps a list of views that may be interested in certain events. Each view is an object that provides a value giving the bitwise Or of the event codes that interest it. For instance, the object that manages the daily appointment area needs to redraw the appointments whenever the user selects a new date. It also needs to redraw the appointments if the user changes an appointment’s start or stop time. This object uses the following value as its mask of interesting events:

CAL_SelectedDateChanged Or CAL_AppointmentChanged

Values describing the events that are interesting to each view object are stored in the program’s Events collection. References to the objects themselves are stored in the corresponding entries in the Views collection.

The NotifyViews subroutine takes as a parameter an event mask that represents the event or events that have just occurred. It uses the bit mask techniques described in the previous section to identify the views that are interested in the events. For each interested view, it invokes the view’s Notify subroutine, passing it the event mask so the routine can tell what event just took place.

Private Sub NotifyViews(event_mask As Long)
Dim i As Integer

    For i = 1 To Views.Count
        ‘ Notify this view if necessary.
        If event_mask And Events.Item(i) Then _
            Views.Item(i).Notify event_mask
    Next i
End Sub

Using the MVC Paradigm

The interactions among AppointmentBook’s various user interface elements are quite complex. For example, when the user clicks the up arrow on the month area’s scroll bar, the following actions take place:

1.  The month area redraws the currently selected date so it no longer has a black background. It then selects the date one week before the currently selected date.

2.  If the newly selected date is above the visible part of the month area, the area redraws to make the new date visible. The scroll bar also adjusts to show the newly selected date’s position within the larger calendar.

3.  The date label above the daily appointment area displays the new date.

4.  The daily appointment area displays the appointments for the newly selected date with the earliest appointment shown at the top.

5.  The daily appointment area’s scroll bar adjusts to show where the daily appointment display is within the day’s schedule.

This is one of AppointmentBook’s more convoluted interactions, but many of the others are complicated enough to be quite confusing. These sorts of interactions can make program maintenance a nightmare. Suppose, for example, the program needed to display daily schedules using a new display method. Adding the new code would require removing all of the code that managed the display using the old method. Changes would be required wherever the program used the old code to update the appointment display. This occurs whenever the user performs one of the following actions:

•  Selects a new date by clicking in the month area, using the month area’s scroll bar, or by invoking the Select Today command in the Appointments menu

•  Creates a new appointment

•  Changes the start or stop time of an existing appointment

•  Deletes an appointment

•  Scrolls the appointments using the daily appointment area’s scroll bar

Removing the older appointment display code would require changes in many different parts of the program.

The model/view/controller (MVC) paradigm uses three different kinds of objects to make managing these sorts of interactions easier. As its name implies, the three kinds of objects MVC uses are called models, views, and controllers.

Briefly, a model is an object that represents some sort of data, device, or some other thing around which the interactions are centered. A view is an object that provides some sort of display of a model. A controller is an object that manipulates a model. The following sections discuss the basic duties of these objects. They also briefly describe the specific duties of the model, view, and controller objects used by AppointmentBook. Some of these objects are described in greater detail a bit later.

The duties of models, views, and controllers are tied tightly together so you may find it difficult to understand how each object works separately. You may need to know how a view works before you can understand models, but you also need to understand models before you can fully understand views. To understand all the details, you may need to read the following sections two or three times.

Models

A model has two duties: managing application data and notifying views when the data is modified. The first duty simplifies the ways in which other parts of the program modify the data. The second makes even the most complicated object interactions manageable.

Managing Application Data It is the model’s duty to manage all aspects of the actual data. The model is the only object that is allowed to do anything to the data directly. Only the model can load, save, modify, or even view the data. Other objects that need to interact with the data must do so using the model’s public subroutines, functions, and property procedures.

For example, in AppointmentBook one of the many pieces of information stored in the model is the currently selected date. The model class CalendarModel provides a property let procedure SelectedDate that allows other parts of the program to select a new date. Code outside the CalendarModel class simply sets the property procedure’s value to the desired date, and the model makes the actual changes to the data.

The following code shows how the Select Today command in the Appointments menu makes the current day the selected date. Visual Basic’s Date function returns the current date. Because all of the data modification details are hidden within the model’s SelectedDate procedure, this code is extremely simple.

Private Sub mnuApptToday_Click()
    TheCalendarModel.SelectedDate = Date
End Sub

Notifying Views The second duty of a model is to notify interested views when an event occurs. In addition to storing a representation of the data, the model must contain a list of view objects that are interested in various events that may occur. When one of the model’s public routines or functions changes the data, the model must inform interested views of the change.

To make view management possible, the model should provide a RegisterView subroutine. This routine takes as parameters a reference to a view object and a bit mask indicating the events that interest the object. The model stores this information for later use.