Share this Page URL

Chapter 5. Using Visual Basic to Automat... > Creating an Event Procedure - Pg. 141

Using Visual Basic to Automate Your Database cmdImport_Click_Err: MsgBox Error$ Resume cmdImport_Click_Exit End Sub 141 Event-driven programming The programming you do in Access is often referred to as event-driven programming. The Import procedure is known as an event procedure because it runs when the event it's associated with occurs. Clicking a button, opening a form, printing a report, updating a record, resizing a window--all of these events and others happen regularly as you work in an Access database. Part of programming Access is handling events in a logical and consistent way. You need to understand and anticipate how a database will be used and respond to its events to avoid errors and make the database easier to work with. DoCmd, which begins the statements DoCmd.SetWarnings and DoCmd.TransferSpreadsheet, is a reference to a part of the Access object model. Objects provide a program with the means to set the properties of a database object and to perform actions on the object. The DoCmd object can perform a number of actions (these actions are known as methods), such as the OpenReport method we used in Chapter 1 or the TransferSpreadsheet method we're working with here. Later in this chapter, we'll describe object models in more detail. You'll see examples of how to use the Access object model as well as other object models that you use to work directly with data and with other Office applications from Access. Annotating your code with comments As the amount of code you use in your databases increases and becomes more complex, remembering what you (or others) intended by each statement or block of code becomes more difficult. To keep the meaning of your code clear, you can add comments to it, as you can with a macro. Comments don't execute when your code runs; they're used to annotate and explain what your code is doing. You can include comments anywhere within a procedure by preceding the comment with a single quotation mark ('). You can add a comment on its own line, as with the comment in the Import procedure, or you can add a comment after a code statement, on the same line. To perform an operation, a method, like a macro, requires information in the form of arguments. The arguments for the TransferSpreadsheet method include the type of transfer ( acImport ), the version of Excel (in this case, version 8), the name of the table to import data into ( "CampaignExpenses" ), the path to the spreadsheet the procedure is importing, and whether the spreadsheet contains field names ( "True" ). Each argument is separated by a comma, and quotation marks set off text values such as the name of the spreadsheet file. The argument acImport is known as a constant. You'll learn more about constants in the section "Using Standard and Class Modules," later in the chapter. We'll describe the code used to handle errors (the statement beginning On Error Go To ) in the section "Handling Errors and Debugging Code." Parameters and arguments Programmers make a distinction between arguments and parameters. When you define a procedure, you specify parameters to indicate the information that needs to be supplied to the procedure. When you actually use the procedure, the values you supply are called arguments. At this point, we'll make a few modifications to the Import procedure and describe more details about the Visual Basic Editor and the different elements of an event procedure. Create an event procedure 1. In the Visual Basic Editor, click Tools, References. You'll see the References dialog box, shown here: