In the Real WorldDealing with Event-Driven Programming

In the Real World Dealing with Event-Driven Programming

Beginning programmers and Web page designers often find that understanding Windows' event-driven programming model to be quite difficult. The same problem befalls many programmers experienced in conventional procedural languages, such as assembly, COBOL, Pascal, and xBase. With a very few exceptions, VBA code in an Access application or script in a DHTML page executes only in response to a predefined event. (The primary exceptions are variable and Windows function prototype declarations that precede VBA subprocedure and function code in modules.)

The first Office data object model that fired events was Access 97's ODBCDirect, an object wrapper over Visual Basic 4.0 Enterprise Edition's Remote Data Object (RDO) 1.0. Being able to intercept data-related events, such as when making a connection or starting and ending query execution, enables you to handle connection errors and asynchronous data operations. An asynchronous data operation is one in which control returns to your program after query execution starts. When the query completes, the corresponding event lets you write code to process the resulting Recordset. Your application isn't in a state of suspended animation while waiting for a "query from hell" to complete.

OLE DB and ActiveX Data Objects (ADO), however, provide a much richer (more granular) event model than ODBCDirect, as demonstrated by the event-related sections of Chapter 30, "Understanding Universal Data Access, OLE DB, and ADO." For optimum front-end VBA programming simplicity and flexibility, it's hard to beat ADO's event model. The .NET Framework's ADO.NET replacement for COM-based ADO, which emphasizes XML representation of DataTable and DataSet objects, dooms ADO and OLE DB to "legacy" status. It's unlikely that you'll see any significant upgrades to the current version, ADO 2.7, that's included in Microsoft Data Access Components (MDAC) 2.7.

The VBA code examples in this chapter cover only the basics of using VBA 6.0 for responding to events triggered by forms, controls, and Recordsets bound to forms or reports. A full course in VBA database programming exceeds both the scope and the publishing limitations of this book. Many of the examples in this chapter are drawn from the sample databases supplied with Access 2003. You can adapt the techniques illustrated in the event-handling subprocedures of the sample databases to custom applications you create.

To become an expert in VBA programming requires study, experimentation, and perseverance. Periodicals, books, and Web sites, such as those listed in the "Other Sources of Information for Access" section of the introduction to this book, are likely to satisfy the studious reader. There's no substitute, however, for experimentation. Writing and testing code is the only sure way to become proficient in Access VBA programming.