Responding to Form and Report Events
Access is an event-driven application. In Access, the occurrence of events triggers some action to occur. Events may be external or internal. External events are such things as a key being pressed or the mouse being moved. Internal events are such things as a form opening or closing, or an error occurring. You take control of Access by providing responses to events. These responses can be running a macro or a VBA event procedure.
NOTE
For a complete list of events, see the online help topic "Events and Event Properties Reference."
VBA event procedures (also known as event handlers) are subprocedures contained in class modules. Access automatically creates a class module when you write an event procedure to respond to an event related to a form or a report. Each form or report can have only one class module that contains all its event procedures.
NOTE
Previous versions of Access used the phrase code behind forms to refer to event procedures that respond to a form's or a report's events. This term is no longer used in Access 97 or Access 2000.
The class module that contains a form's event procedures is an integral part of that form. For that reason, if you make a copy of the form, the copy contains the class module with all its event procedures. The same is true for class modules that contain a report's event procedures. You can take advantage of this to save a lot of time if you have similar forms or reports within a single application, or if you have similar forms or reports in different applications.
The next few sections refer specifically to forms. Much of the information in those sections applies also to reports.
Creating Event Procedures for a Form's Events
You can create event procedures that run at the time a form opens or closes.
When you open a form, a sequence of events occurs in the order listed in Table 1.
Table 1 Events That Occur When a Form Opens
|
Event |
Occurs |
|
Open |
After a form opens but before it displays values in its controls |
|
Load |
After values are displayed in the form's controls |
|
Resize |
Immediately after the Load event and also after the size of a form changes |
|
Activate |
When the form becomes active |
|
GotFocus |
Only if the form contains no visible controls or if all visible controls are disabled |
|
Current |
When a form is opened and also when the focus changes from one record to another |
When you close a form, a sequence of events occurs in the order listed in Table 2.
Table 2 Events That Occur When a Form Closes
|
Event |
Occurs |
|
Unload |
After a form is closed but before it is removed from the screen |
|
LostFocus |
Only if the form contains no visible controls or if all visible controls are disabled |
|
Deactivate |
When a form loses the focus to another form or to a Table, Query, Report, Macro, Module, or Database window |
|
Close |
After a form is closed and removed from the screen |
When you switch between two open forms, the Deactivate event occurs for the currently active form and then the Activate event occurs for the newly active form.
It's very important to pay attention to when specific events occur and to the order in which they occur. For example, if you need an event procedure that runs when a form opens and also runs when you switch from one open form to another, you must create an event procedure that runs when the Activate event occurs. In contrast, if you want an event procedure to run when a form opens but not when you switch from one open form to another, you should create an event procedure that responds to the Open or Load event.
NOTE
After you've created an event procedure that responds to a form event, test that procedure carefully to make sure that it runs when you want it to and doesn't run when you don't want it to.
Creating an Event Procedure That Responds to a Form Event
A form has many events to which it can respond, as shown in Figure 3.
){kind=link}
Figure 3 The Event tab in a form's Property sheet shows all the events to which a form can respond.
To gain a detailed understanding of how forms work, I urge you to become familiar with each of the events a form can respond to. It's not necessary to understand each event in detail; just become familiar with the nature of each event. When you want to use a specific event, you can access Help to get all the information you need.
NOTE
You can find detailed information about each of the events listed in Figure 3 by opening the "Events and Event Properties Reference" topic in Help. That topic contains an alphabetical listing of events. Click any event name to see information about that event.
To create an event procedure that responds to one of a form's events, follow these steps.
-
Display the form in Design view. If necessary, choose View, Properties to display the Property sheet.
-
Verify that the Property sheet's title bar contains the word Form. If not, click the button at the left end of the form's horizontal ruler.
-
Display the Property sheet's Event tab, as previously shown in Figure 3.
-
Click the name of the event for which you want to create an event procedure, such as On Load. A Builder button containing three dots appears at the right of the property box.
-
Click the Builder button to display the Choose Builder dialog box.
-
Select Code Builder and choose OK. Access displays the Visual Basic Editor (VBE) window shown in Figure 4.
){kind=link}
Figure 4 The VBE window opens with the first and last statements of the new procedure displayed.
The first and last statements of the new procedure are known as a stub. It's up to you to place statements within the stub that control what happens when the event occurs. For example, if the form contains certain command buttons, you might want to enable and disable specific buttons so that only those that are useful immediately after the Load event occurs are enabled. Assuming that you have command buttons named cmdNew, cmdSave, cmdDelete, and cmdClose, you would enter code so that the command procedure consists of these statements:
Private Sub Form_Load() cmdNew.Enabled = True cmdSave.Enabled = False cmdDelete.Enabled = True cmdClose.Enabled = True End Sub
Canceling an Event
Some—but, by no means all—event procedures allow you to cancel the associated event. For example, you can include code in a Form_Open event procedure to cancel the Open event; however, you can't include code in a Form_Load event procedure to cancel the Load event.
Figure 5 shows the stub for a Form_Open event procedure.
){kind=link}
Figure 5 The first statement in a Form_Open event procedure includes the argument Cancel As Integer.
An argument is a value that's passed to a procedure. Arguments are listed in the first statement of a procedure after the procedure's name and are enclosed within a pair of parentheses. Each argument is a variable that has a name (Cancel, in this case) and a data type (Integer, in this case). Only one argument is shown in Figure 5. Procedures can have more than one argument, in which case each argument is separated from the next by a comma.
NOTE
Arguments are sometimes referred to as parameters. Because the word parameter has a special meaning in the context of queries within Access, I prefer to use argument for a value passed to a procedure.
When you create a stub for an event procedure such as Form_Open, the value of the Cancel argument is 0 (zero), which is the numerical equivalent of False. The argument's value remains unchanged unless you include code within the procedure to change it to True (or a numerical value other than 0). With the Cancel argument set to False, the argument has no effect—the Open event occurs, and whatever statements are in the Open event procedure are executed.
Within the Open event procedure, you can include this statement
Cancel = True
which has the effect of canceling the Open event. If this code is executed within the event procedure, the form doesn't open.
There's no point in writing a Form_Open event procedure in which the Cancel variable is always set to True—that would mean that the form never opens. Instead, the Cancel variable is set to True within an If control structure or some other control structure that tests for a certain condition(s). If that condition occurs, your code should display a message to the user and then set the Cancel variable to True. For example, if you didn't want anyone to be able to open a form on a Sunday, you could write a Form_Open event procedure such as that in Listing 1.
Listing 1 VBA Code to Demonstrate the Use of the Cancel Argument
Private Sub Form_Open(Cancel As Integer)
If Weekday(Date) = vbSunday Then
MsgBox "You can't open this form on a Sunday!"
Cancel = True
End If
'Insert code here to control what happens when the
'form opens on any day other than Sunday
End Sub
The first statement in the If control structure makes use of two Access functions. The Date function returns the current system date. The Weekday function returns the number of the day of the week. If the current date corresponds to a Sunday, Weekday(Date) returns a value of 1 (one), which corresponds to the Visual Basic intrinsic constant vbSunday. Consequently, the condition is true, so the two statements within the If control structure execute. For any other day, the condition is not true, so the two statements within the If control structure don't execute, the value of the Cancel variable remains False, and the form opens Argument.
Responding to Control Events
Controls, as you know, are objects that you place on forms and reports. These objects include labels, text boxes, option buttons, check boxes, command buttons, list boxes, combo boxes, and more. Each of these controls can respond to various events. For example, the events to which command buttons can respond are listed in Figure 6.
){kind=link}
Figure 6 These are the events to which a command button can respond.
Although the On Click event for a command button is the event you'll use most frequently, take some time to understand the other events you can use.
You can create event procedures for controls in the same way that you create event procedures for forms and reports, as described in the section "Creating Event Procedures for a Form's Events," previously in this chapter.