MS-Access / Getting Started

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
EventWhen the Event Is Triggered
OpenWhen a form is opened, but the first record is not displayed yet
LoadWhen a form is loaded into memory but not yet opened
ResizeWhen the size of a form changes
UnloadWhen a form is closed and the records unload, and before the form is removed from the screen
CloseWhen a form is closed and removed from the screen
ActiveWhen an open form receives the focus, becoming the active window
DeactiveWhen a different window becomes the active window, but before it loses focus
GotFocusWhen a form with no active or enabled controls receives the focus
LostFocusWhen a form loses the focus
TimerWhen a specified time interval passes. The interval (in milliseconds) is specified by the TimerInterval property.
BeforeScreenTipWhen 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
EventWhen the Event Is Triggered
ClickWhen the user presses and releases (clicks) the left mouse button
DblClickWhen the user presses and releases (clicks) the left mouse button twice on a form
MouseDownWhen the user presses the mouse button while the pointer is on a form
MouseMoveWhen the user moves the mouse pointer over an area of a form
MouseUpWhen the user releases a pressed mouse button while the pointer is on a form
MouseWheelWhen the user spins the mouse wheel
KeyDownWhen the user presses any key on the keyboard when a form has focus or when the user uses a SendKeys macro action
KeyUpWhen the user releases a pressed key or immediately after the user uses a SendKeys macro action
KeyPressWhen 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
EventWhen the Event Is Triggered
CurrentWhen you move to a different record and make it the current record
BeforeInsertAfter data is first entered into a new record, but before the record is actually created
AfterInsertAfter the new record is added to the table
BeforeUpdateBefore changed data is updated in a record
AfterUpdateAfter changed data is updated in a record
DirtyWhen a record is modified
UndoWhen a user has returned a form to clean state (the record has been set back to an unmodified state); the opposite of OnDirty
DeleteWhen a record is deleted, but before the deletion takes place
BeforeDelConfirmJust before Access displays the Delete Confirm dialog box
AfterDelConfirmAfter the Delete Confirm dialog box closes and confirmation has happened
ErrorWhen a runtime error is produced
FilterWhen a filter has been specified, but before it is applied
ApplyFilterAfter 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.

[Previous] [Contents] [Next]