Introducing Event-Driven Programming

All Windows applications are event-driven, which means that an event, such as a mouse click on a command button or a change in the position of a record pointer, executes individual blocks of application programming code. Thus, the majority of the VBA code you write consists of event-handling subprocedures also called event procedures or event handlers that are contained within [{ Public| Private}] Sub {Form|Report}_[ObjectName_] EventName...End Sub structures of class modules. Class module is the VBA term that replaces Access 2.0's and Access 95's use of code-behind-forms (CBF) to describe Access Basic or Access-specific VBA code embedded within a Form or Report container. This chapter describes how to write Access VBA event-handling code in Form and Report class modules to automate your Access 2003 applications.

Early versions of Access emphasized the use of Access macros to respond to events. Microsoft promoted Access macros as a simplified programming language for users with little or no programming experience. The original repertoire of about 40 Access macro actions proved adequate to automate relatively simple applications. One of the major drawbacks of Access macros is the inability to handle errors gracefully. Thus, virtually all Access power users and developers have abandoned macros in favor of programming. There's no guarantee that future versions of Access will continue to support Access macros.