Access 2003 VBA Programmer's Reference

Chapter 8. Executing VBA

In the old days of programming, procedural languages ruled, meaning that the overall program execution traveled from top to bottom. The main body of any of these programs had to cover every possibility: display a screen to the user, gather input, perform edit checking, display messages, update the database (or simple files in those days), and close when everything was done. The main program also had to cover every option or side request that the user might make. This made it difficult to understand the entire program, and it was tough to make changes because everything had to be retested when a modification was made. These lumbering beasts included COBOL, RPG, Pascal, and earlier forms of Basic. Millions of lines of code were written in these languages.

Fortunately, those days are over for VBA programmers. VBA is an event-driven language. In every Access form and report there are a variety of events that are waiting for you to use. They are available when the form opens and closes, when records are updated, even when individual fields on the screen are changed. It's all there at your fingertips. Each event can contain a procedure, which is finally where we get back to our procedural roots. Although each procedure runs from top to bottom, just like in the old days, it only runs when the event fires. Until then, it sleeps quietly, not complicating your logic or slowing down your program.

Event-driven programming makes it much easier to handle complex programming ...