What Is Visual Basic?

Visual Basic is the programming language for Microsoft Access. You use it for the same reason you use macros—to tie the objects in your application together into a coherent system. The difference is that Visual Basic provides more power and a finer degree of control than you get by using macros alone.

Some Familiar Territory for the Seasoned Programmer

Visual Basic is a modern programming language that strongly resembles most of the popular, structured programming languages. If you’re a Pascal or C programmer, you’ll find all the program structures you’re used to—loops, If...Then...Else statements, Select Case statements, functions, and subroutines—with only superficial differences. With all its improvements from earlier versions of Basic, Visual Basic retains its English-like flavor and ease of use.

When to Use Visual Basic Instead of Macros

With Microsoft Access, you can accomplish many tasks with macros or through the user interface that require programming in other database systems. So, when do you turn to Visual Basic? It depends on what you want to do.

Why Use Visual Basic?

You’ll want to use Visual Basic instead of macros if you want to do any of the following:

• Make your application easier to maintain Because macros are separate objects from the forms and reports that use them, an application containing a large number of macros that respond to events on forms and reports can become difficult for you, the application developer, to maintain. In contrast, when you use Visual Basic to respond to events, your code is built into the form or report’s definition. If you move a form or report from one database to another, the Visual Basic code built into the form or report moves with it. (Code is a general term for the statements you write in a programming language.)
• Create your own functions Microsoft Access includes many built-in, or intrinsic, functions—such as the IPmt function that calculates an interest payment. You can use these functions to perform calculations without having to create complicated expressions. Using Visual Basic, you can also create your own functions to either perform calculations that exceed the capability of an expression or replace complex expressions you’ve written in your application.

  See Also   For more information on creating a function, see “Creating Your First Function” later in this chapter.

• Mask error messages When something unexpected happens in your application and Microsoft Access displays an error message, the message can be quite mysterious to your application’s users, especially if they aren’t familiar with Microsoft Access. Using Visual Basic, you can detect the error when it occurs and display your own message, or you can have your application do something else. Applications used by a variety of people almost always require some Visual Basic code for handling errors.

  See Also   For more information on handling errors in your application, see Chapter 8, “Handling Run-Time Errors.”

• Create or manipulate objects In most cases, you’ll find that it’s easiest to create and modify an object in that object’s Design view. In some situations, however, you may want to manipulate the definition of an object in code. Using Visual Basic, you can manipulate all the objects in a database, including the database itself. A Microsoft Access wizard is a good example of an application that creates and modifies objects using code. For example, the Form Wizard is a collection of Visual Basic functions that creates a form according to the specifications supplied by the user.
• Perform system-level actions You can use the RunApp action in a macro to run another Windows-based or MS-DOS®-based application from your Microsoft Access application, but you can’t use a macro to do much else outside Microsoft Access. Using Visual Basic, you can check to see if a file exists on the system, use Automation or dynamic data exchange (DDE) to communicate with other Windows-based applications such as Microsoft Excel, and call functions in Windows dynamic-link libraries (DLLs).
• Manipulate records one at a time You can use Visual Basic to step through a set of records one record at a time and perform an operation on each record. In contrast, macros work with entire sets of records at once.
• Pass arguments to your code An argument is a value that supplies the additional information that some actions require. You set arguments for macro actions in the lower part of the Macro window when you create the macro; you can’t change them when the macro is running. With Visual Basic, however, you can pass arguments to your code at the time it runs. You can even use variables for arguments—something you can’t do in macros. This gives you a great deal of flexibility in how your code runs.

  

Tip   Although you can have both macros and Visual Basic code in your application, you may find it easier to use Visual Basic exclusively once you get started programming. If you have macros in your application, Microsoft Access can automatically convert them to event procedures or modules that perform all the equivalent actions in Visual Basic code.

In form or report Design view, use the Convert Macros To Visual Basic command (Tools menu, Macro submenu). For global macros that aren’t attached to a specific form or report, use the Save As/Export command (File menu) to save the macro as a module. For more information, search the Help index for “macros, converting.”

Why Use Macros?

After reading all the reasons for using Visual Basic, you may wonder if there are any reasons left for using macros. However, macros do have their place in many applications. Macros are an easy way to take care of simple details such as opening and closing forms, showing and hiding toolbars, and running reports. Because you specify options for each action in the lower part of the Macro window, there’s little syntax to remember, and developing applications can often be faster than with Visual Basic.

In addition to the ease of use macros provide, creating a macro is the only way to make global key assignments.

See Also   For information on assigning keys with an AutoKeys macro, see Chapter 1, “Creating an Application.”

How an Event-Driven Application Works

An event is an action recognized by a form, report, or control. Each type of object in Microsoft Access automatically recognizes a predefined set of events. When you want a form, report, or control to respond to an event in a particular way, you can write a Visual Basic event procedure for that event.

Here’s what happens in a typical event-driven application:

1. A user starts the application and Microsoft Access automatically opens the startup form specified in the Startup dialog box.
2. The startup form, or a control on the startup form, receives an event. The event can be caused by the user (for example, a keystroke or mouse click), or by your code (for example, an Open event when your code opens a form).
3. If there is an event procedure corresponding to that event, it runs.
4. The application waits for the next event.

Note   Some events automatically trigger other events. For example, when the MouseDown event occurs, the MouseUp and Click events immediately follow.

Event-Driven vs. Traditional Programming

In a traditional procedural program, the application rather than an event controls the portions of code that are run. It begins with the first line of code and follows a defined pathway through the application, calling procedures as needed.

In event-driven applications, a user action or system event runs an event procedure. Thus, the order in which your code is run depends on the order in which events occur; the order in which events occur is determined by the user’s actions. This is the essence of graphical user interfaces and event-driven programming: The user is in charge, and your code responds accordingly.

Because you can’t predict what the user will do, your code must make a few assumptions about “the state of the world” when it runs. It is important that you either test these assumptions before running your code or try to structure your application so that the assumptions are always valid. For example, if your application assumes that a text box has text in it before the user clicks a command button, you can write code to enable the command button only when the Change event for the text box occurs.

See Also   For information on events, see Chapter 6, “Responding to Events.”