Most operations in Microsoft Access involve a sequence of events. For example, the process of opening a form usually includes the following sequence:
Other events also occur when the previously active window becomes inactive and the focus moves to an object in the new active window. The full sequence of events in typical situations is explored later in this chapter.
See Also For more information on the order of events, search the Help index for “events, order of.”
Because each step in opening a form is a separate event, your application can run a macro or a procedure exactly when you want it to. For example, your application can close another window or preset the focus in the new active window before the first record is displayed. Or it can display a custom toolbar on the form when its window becomes active.
You can also cancel many events. For example, you can prevent a form from opening if certain conditions are not met by including code in the form’s Open event procedure that cancels the Open event when an expression evaluates to True.
See Also For more information on canceling events, see “Canceling Events” later in this chapter.
Microsoft Access events fall into several categories. The following table summarizes these event categories.
| Event category | Events | Occur when |
| Window events | Close, Load, Open, Resize, Unload | A user or code opens, resizes, or closes a form or report. |
| Focus events | Activate, Deactivate, Enter, Exit, GotFocus, LostFocus | Objects receive or lose the focus, or become active or inactive. |
| Data events | AfterDelConfirm, AfterInsert, AfterUpdate, BeforeDelConfirm, BeforeInsert, BeforeUpdate, Change, Current, Delete, NotInList, Updated | A user or code enters, deletes, or changes data in a form or control, or moves the focus from one record to another. |
| Mouse events | Click, DblClick, MouseDown, MouseMove, MouseUp | A user performs a mouse action, such as clicking or double-clicking. |
| Keyboard events | KeyDown, KeyPress, KeyUp | A user types on the keyboard, or keys are sent using the SendKeys action or the SendKeys statement. |
| Print events | Format, NoData, Page, Print, Retreat | A report is being printed, or is being formatted for printing. |
| Filter events | ApplyFilter, Filter | A user creates, applies, or removes a filter for a form. |
| Error and Timing events | Error, Timer | Microsoft Access or the Jet database engine encounters an error, or a specified time interval passes. |
See Also For more information on each of these events and examples of how to respond to them in your application, search the Help index for “events, listed alphabetically” or for the name of a particular event.
Opening a form triggers a sequence of events, including the Open, Load, Resize, and Activate events. In addition, if no control on the form can receive the focus, a GotFocus event occurs for the form itself. Other events occur as you work with the form and its controls. You can write macros or Visual Basic code for any of these events, so you have a fine degree of control over how your application behaves.
See Also To see the sequence of events that occurs when you work with forms and controls, open the ShowEvents form in the Orders sample application.
Because opening forms, moving between forms, and working with controls are some of the most common operations in a Microsoft Access application, understanding the order of these events is one of the keys to effective application development. This section describes the sequence of events for some common form and control operations.
When you first open a form that contains an active control—one that can receive the focus—the following sequence of events occurs for the form:
If there are no active controls on the form, Microsoft Access also triggers a GotFocus event for the form, after the Activate event, but before the Current event.
When you close a form that contains an active control, Microsoft Access triggers the following sequence of events for the form:
If there are no active controls on the form, Microsoft Access triggers a LostFocus event for the form after the Unload event, but before the Deactivate event.
When you open a form that contains one or more active controls, an Enter event occurs, followed by a GotFocus event, for the control receiving the focus. These events occur after the form’s Activate and Current events:
Both events occur when a control first receives the focus. If you switch to a different form and then return to the same control on the first form, Microsoft Access triggers a GotFocus event for the control, but not an Enter event.
When you exit a control—for example, when you select another control on the same form—the following events occur for the control:
When you switch between two open forms that contain active controls, Microsoft Access triggers a Deactivate event on the first form and an Activate event on the second form:
Note An Open event doesn’t occur on a form that is already open but not activated, whether you switch to the form or run a macro that specifies the form in an OpenForm action. If you want your application to run the code in a form’s Open event procedure when the form is already open, you can:
If there are no active controls on the forms, Microsoft Access also triggers the LostFocus and GotFocus events:
This example shows the sequence of events that are triggered in a typical scenario while you work with forms and controls.
Step One: Open a form Open the form Form1, whose first active control is Control1.
Step Two: Open a second form Open the form Form2, whose first active control is Control2.
There is no Exit(Control1) event, because the object that receives the focus is on a different form.
Step Three: Return to the first form Click on the first form.
Control1 now has the focus. There is no Enter(Control1) event because Control1 had the focus when Form1 was last active.
Step Four: Click another control on the first form Click a different control, Control3, on the second form.
Step Five: Click another control on the second form Click a different control, Control4, on the second form.
When you press a key, Microsoft Access triggers the KeyDown, KeyPress, and KeyUp events for the form or control that has the focus. When a control has the focus, you’ll normally want the control to receive all keystrokes when changing data in a text box.
See Also For information on responding to changes to text and data, see the following section, “Working with Data.”
In some cases, however, you’ll want to respond to specific keys pressed in a form, regardless of which control has the focus. For example, you may want to perform some action whenever the user presses a key combination such as CTRL+Y. You can make sure that the form receives all key events, even those that occur in controls, by setting the KeyPreview property for the form to Yes. With this property setting, all key events occur first for the form, and then for the control that has the focus.
You can respond to specific keys in the form’s KeyPress, KeyDown, or KeyUp events. The KeyPress event responds only to the ANSI characters generated by the keyboard. ANSI characters are generated by the following keys and key combinations: any printable keyboard character, CTRL+A through CTRL+Z, ENTER, CTRL+ENTER, BACKSPACE, CTRL+BACKSPACE, and TAB. The KeyPress event ignores all other keystrokes. In most cases, it is simplest to use only the KeyPress event to respond to keyboard events.
The following sample code demonstrates how to respond to the CTRL+Y key combination in a form by using the KeyPress event. Note that you can prevent the control from getting keystrokes you respond to by setting the KeyAscii argument to zero.
Private Sub Form_KeyPress (KeyAscii As Integer)
Const conCtrlYCode = 25 ' ANSI character code for CTRL+Y.
If KeyAscii = conCtrlYCode Then
MsgBox "You pressed Ctrl+Y"
KeyAscii = 0 ' Do not send key on to control.
End If
End Sub
The KeyDown and KeyUp events work on a lower level by responding to events generated by the keys themselves being pressed and released. Use KeyDown and KeyUp events if you need to respond to keys that don’t generate ANSI characters, such as the function keys (F1 through F12), or if you need to respond to key combinations that include the SHIFT, ALT, and CTRL keys (except the CTRL key combinations that respond to the KeyPress event).
See Also For information on responding to keystrokes by using the KeyDown and KeyUp events, search the Help index for “KeyDown event” and “KeyUp event.”
You can use data events in your application to respond to many types of changes to records and data. For example, the application can run a macro or an event procedure in response to:
Note Some events do not occur when you use Visual Basic code to manipulate data in your application—for example, the Change event, the BeforeInsert event, and the AfterInsert event.
See Also To see the sequence of events that occurs when you work with data, open the ShowEvents form in the Orders sample application.
When you change text in a text box or combo box, a Change event occurs. The event occurs whenever the contents of a control changes, but before you move to a different control or record. For example, when you delete a character in a text box by pressing the BACKSPACE key, Microsoft Access triggers the following sequence of events:
If you then type one or more characters in the text box, Microsoft Access recognizes the same sequence of events for each keystroke. Note that the KeyPress event doesn’t occur if you delete a character by using the DELETE key, only if you use the BACKSPACE key.
The Change event doesn’t occur when a value changes in a calculated control, or when you select an item from a combo box list.
When you update data in a control by moving to a different control on the form, Microsoft Access triggers the BeforeUpdate and AfterUpdate events for the control. The BeforeUpdate event occurs just before the data is updated; the AfterUpdate event occurs after the update.
For example, if you update data in a text box (TB1) by deleting a character, then click a different text box (TB2), Microsoft Access triggers the following sequence of events:
If you update a control or record by moving to a different record or by clicking Save Record on the Records menu, the BeforeUpdate and AfterUpdate events for both the control and the form occur. For example, if you delete a character in a text box and then click Save Record on the Records menu, the following sequence of events occurs:
When you update a control or record by moving to a different record, Microsoft Access triggers several events after the BeforeUpdate and AfterUpdate events for the control and form: It triggers Exit and LostFocus events for the control losing the focus, the Current event for the new record, and Enter and GotFocus events for the control receiving the focus.
When you enter data in a new record by way of the user interface, Microsoft Access triggers a BeforeInsert event when you first enter data in the record, and an AfterInsert event when the record is saved.
This example shows the sequence of events that Microsoft Access triggers in a typical scenario when you enter data in a new record.
Step One: Enter text in the first field of a new record After clicking Data Entry on the Records menu of a form to display a blank record, type a character in a text box (TB1).
Step Two: Move to another field of the same record and enter text Click another text box (TB2) on the form and type a character.
Step Three: Save the new record Click Save Record on the Records menu.
When you select a record and delete it (either by pressing the DELETE key or by clicking Delete on the Edit menu), Microsoft Access triggers the Delete event, and then the Current event. If you select multiple records and delete them, the Delete event occurs once for each record that you have selected, and then Microsoft Access triggers the Current event. Unless you cancel the Delete event, Microsoft Access also triggers BeforeDelConfirm and AfterDelConfirm events. You use these events to control how record deletions are confirmed.
For example, when you select a record on a form and delete it, Microsoft Access by default:
If you want, you can prevent this dialog box from appearing in two ways. You can cancel the BeforeDelConfirm event, in which case the deletion is canceled. Or you can set the Response argument of the BeforeDelConfirm event procedure to acDataErrContinue, in which case the deletion is confirmed.
Your BeforeDelConfirm event procedure can display a custom dialog box and handle the user’s responses.