Form event procedures
When you work with forms, you can create event procedures based on events at the form level, the section level, or the control level. If you attach an event procedure to a form-level event, whenever the event occurs, the action takes effect against the form as a whole (such as when you move to another record or leave the form).
To have your form respond to an event, you write an event procedure and attach it to the event property in the form that recognizes the event. Many properties can be used to trigger event procedures at the form level.
Note: Form events execute when moving from one record to another or when a form is being opened or closed. I cover control events in the "Control event procedures" section, later in this tutorial.
Essential form events
Access forms respond to many, many events. You'll never write code for most of these events because of their specialized nature. There are, however, some events that you'll program over and over again in your Access applications. Table 12.2 lists some of the most fundamental and important Access form events. Not coincidentally, these are also the most commonly programmed Access form events.
In Table-2, notice how many events are related to data (Current, BeforeInsert, and so on). Because Access forms are usually involved in working with data (adding new data, editing, and so on), Access forms include these events to provide you with a high level of control over data management.
Table-2: Essential Form Events| Event | When the Event Is Triggered |
|---|---|
| Open | When a form is opened, but the first record is not displayed yet |
| Load | When a form is loaded into memory but not yet opened |
| Resize | When the size of a form changes |
| Unload | When a form is closed and the records unload, and before the form is removed from the screen |
| Close | When a form is closed and removed from the screen |
| Active | When an open form receives the focus, becoming the active window |
| Deactive | When a different window becomes the active window, but before it loses focus |
| GotFocus | When a form with no active or enabled controls receives the focus |
| LostFocus | When a form loses the focus |
| Timer | When a specified time interval passes. The interval (in milliseconds) is specified by the TimerInterval property. |
| BeforeScreenTip | When a screen tip is activated |
Form mouse and keyboard events
Access forms also respond to a number of mouse and keyboard events, as shown in Table-3.
Table-3: Form Mouse and Keyboard Events| Event | When the Event Is Triggered |
|---|---|
| Click | When the user presses and releases (clicks) the left mouse button |
| DblClick | When the user presses and releases (clicks) the left mouse button twice on a form |
| MouseDown | When the user presses the mouse button while the pointer is on a form |
| MouseMove | When the user moves the mouse pointer over an area of a form |
| MouseUp | When the user releases a pressed mouse button while the pointer is on a form |
| MouseWheel | When the user spins the mouse wheel |
| KeyDown | When the user presses any key on the keyboard when a form has focus or when the user uses a SendKeys macro action |
| KeyUp | When the user releases a pressed key or immediately after the user uses a SendKeys macro action |
| KeyPress | When the user presses and releases a key on a form that has the focus or when the user uses a SendKeys macro |
In addition, the KeyPreview property is closely related to form keyboard events. This property (which is found only in forms) instructs Access to allow the form to see keyboard events before the controls on the form. By default, the controls on an Access form receive events before the form. For example, when you click on a button on a form, the button - not the form - sees the click, even though the form supports a Click event. This means that a form's controls mask key events from the form, and the form can never respond to those events. You must set the KeyPreview property to Yes (true) before the form responds to any of the key events (KeyDown, KeyUp, and so on).
Form data events
The primary purpose of Access forms is to display data. Not surprisingly then, Access forms have a number of events that are directly related to a form's data management.You'll encounter event procedures written for these events virtually every time you work on an Access application. These events are summarized in Table-4.
Table-4: Form Data Events| Event | When the Event Is Triggered |
|---|---|
| Current | When you move to a different record and make it the current record |
| BeforeInsert | After data is first entered into a new record, but before the record is actually created |
| AfterInsert | After the new record is added to the table |
| BeforeUpdate | Before changed data is updated in a record |
| AfterUpdate | After changed data is updated in a record |
| Dirty | When a record is modified |
| Undo | When a user has returned a form to clean state (the record has been set back to an unmodified state); the opposite of OnDirty |
| Delete | When a record is deleted, but before the deletion takes place |
| BeforeDelConfirm | Just before Access displays the Delete Confirm dialog box |
| AfterDelConfirm | After the Delete Confirm dialog box closes and confirmation has happened |
| Error | When a runtime error is produced |
| Filter | When a filter has been specified, but before it is applied |
| ApplyFilter | After a filter is applied to a form |
The Current event fires just after the data on a form is refreshed. Most often this occurs as the user moves the form to a different record in the recordset underlying the form. The Current event is often used to perform calculations based on the form's data or to format controls. For example, if a certain numeric or date value is outside of an expected range, the Current event can be used to change the text box's BackColor property so the user notices the issue.
The BeforeInsert and AfterInsert events are related to transferring a new record from the form to an underlying data source. BeforeInsert fires as Access is about to transfer the data, and AfterInsert is triggered after the record is committed to the data source. For example, you could use these events to perform a logging operation that keeps track of additions to a table.
The BeforeUpdate and AfterUpdate events are frequently used to validate data before it's sent to the underlying data source. As you'll see later in this tutorial, many form controls also support BeforeUpdate and AfterUpdate. A control's update is triggered as soon as the data in the control is changed.
Tip: A form's Update event fires much later than the BeforeInsert or AfterInsert events. The Update event occurs just as the form prepares to move to another record. Many developers use the form's BeforeUpdate event to scan all the controls on the form to ensure that all the data in the form's controls is valid. A form's BeforeUpdate event includes a Cancel parameter that, when set to True, causes the BeforeUpdate event to terminate. Canceling an update event is an effective way to protect the integrity of the data behind an Access application.
Tip: Users often want to be notified of pending updates before they move off a record to another record. By default, Access forms automatically update a form's underlying data source as the user moves to another record or closes the form. The Dirty event fires whenever the user changes any of the data on a form. You can use the Dirty event to set a module-level Boolean (true/false) variable (let's call it boolDirty) so that other controls on the form (such as a close button) know that pending changes exist on the form. If bool- Dirty is True when the close button is clicked or when the BeforeUpdate event fires, you can display an Are you sure? message box to confirm the user's intention to commit the changes to the database.
