Chapter 17: Understanding Event Processing

Although you can make Microsoft Office Access 2007 do a lot for you by setting properties when you design forms and reports, you really can’t make your application “come alive” until you build macros or Visual Basic procedures that respond to events. An event can be as simple as the user clicking a button-and your code responds by opening a related form or report. An event can also trigger complex actions, such as creating a booking record when the user selects an available room.

In this chapter, you’ll first learn what event processing is all about-both in Microsoft Windows and specifically within Office Access 2007. The second part of the chapter contains a comprehensive reference for all the events available within Access, a discussion of event sequence, and a list of the specific macro actions you can use to respond to events.

Access as a Windows Event-Driven Application

If you’re reading this book, you’re using the 2007 Microsoft Office system and Windows. You probably use Windows every day and don’t give a second thought to how it actually works. Understanding Windows is essential to programming events in Access 2007.

Understanding Events in Windows

Windows is an event-driven and message-based operating system. When you start an application on your system, that application sends messages to Windows to tell Windows that it wants to respond to certain events. When an event occurs (such as resting your mouse pointer on the application window or clicking somewhere), Windows sends a message to the application to notify it that the event happened. The message usually includes critical information, such as the location of the mouse pointer when the event occurred. The application then responds to the event-usually by sending a message to Windows to act upon the event. Figure 17–1 shows you a conceptual view of this process.

Figure 17–1: Applications running in Windows send messages and respond to events.

For example, when you have Windows Explorer open and click a file name, Windows sends a message to Windows Explorer to tell it where you clicked. Windows Explorer sends a message back to Windows to tell it to highlight what you selected. Another example is the clock utility that runs on your taskbar. Windows starts this utility when Windows initializes unless you’ve set a taskbar option to not display the clock. When the utility starts, it asks Windows to notify it when the system clock time changes. When the clock utility receives a message from Windows that the system clock time has changed to a different minute, it sends a message back to Windows to tell it to change the characters displayed on the taskbar.

The most important aspect of this entire process is that the user is in control of the applications that are running. As the user of your personal computer, you decide what you want the applications to do next. And because Windows can handle multiple messages at a time, you can start a process in an application (perhaps a search in Windows Explorer for a file) and then switch to or start another application to do something else (such as playing a game of solitaire while you wait for the search to finish).

Leveraging Access Events to Build an Application

If you think of forms and reports in your Access application as little applications running under Access, you have the right idea. When you set an event property (one of the properties on the Event tab in the property sheet in a report, a form, or a control on a form or report that points to a macro or a Visual Basic procedure, you’re notifying Access that you want to respond to that event. The code you write in your macro or Visual Basic procedure provides the response to the occurrence of the event.

Access passes on to forms, reports, and controls on forms and reports some typical Windows events such as mouse clicks (the Click and DblClick events) or characters entered from the keyboard (the Change, KeyDown, and KeyPress events). Access also defines a wide range of events that are specific to the objects it supports. For example, the BeforeUpdate event signals that the value in a control is about to change or a record being edited in the form is about to be saved. You can perform data validation in your macro or Visual Basic code that responds to BeforeUpdate and have your macro or code send a message back to Access to cancel the save if some business rule is about to be violated.

Although events in Access occur in a specific sequence, you should keep in mind that other events can occur while any code you’ve written to respond to an event is running. Also, some events signal that an action is about to happen but might not have completed yet. For example, the form Open event signals that a command has been issued to open the form, but the form isn’t displayed on the screen yet.

The next section gives you a comprehensive overview of all events in Access 2007 and describes how you can use them.