UNDERSTANDING WHERE MACROS END AND CODE BEGINS
Many developers who get into Access skip over the step of using macros to automate applications. But there are some tasks that must be performed using macros rather than code.
When Are Macros Necessary?
The Access team at Microsoft have worked hard to whittle down the need to use macros. The tasks that macros are still needed for are as follows:
You use Autokeys macros create key combinations. A common example is using ^P to print (where ^ is used for the Ctrl key). Third-party vendors and developers who are creating “Office-compatible” applications use Autokeys to include necessary key combinations.
You can use Access as a DDE server for other Windows applications. When another application wants Access to execute commands, it will need to call a macro action while using DDE. (For more information on DDE, see Chapter 13, “Driving Office Applications with Automation and DDE.”)
Tip
In the past you used an AutoExec macro to handle whatever actions you wanted to perform when the database was opened. Now a Startup Form property is available from the Tools menu's Startup command. On the form you specify, create an init routine off one of the events, such as the load event, in the form specified in the property labeled Display Form in the Startup dialog.
Note
In versions before Access 97, menus were created by using a combination of the AddMenu macro action and the actions to perform for the menu choices. Macro menu actions still exist in Access 2000 for backward compatibility. However, you can now use command bars that are set to the type Menu. For more information on using command bars, see Chapter 20, “Programming Office Command Bars and the Office Assistant.”
When Is Code Necessary?
A single book really can't list the total number of tasks that require code, because you're limited to your imagination in creating tasks using VBA. Some tasks that can't be performed by using macros are as follows:
Error handling. When you're using macros and an error occurs in the Access retail product, because you have no control whatsoever, you get a couple of gray error boxes and are sent back to where you started that command. With the application that's distributed with the Office Developers Edition Tools, when errors occur, you get dumped out to Windows.
In VBA, on the other hand, you can use error-handling commands to trap errors and handle them gracefully. (For more information on error handling, see Chapter 7, “Handling Your Errors in Access with VBA.”)
Automation and DDE, used for communicating with other applications. (For more information on Automation and DDE, see Chapter 13.)
Transaction processing. This gives developers control over completing a task or rolling it back.
Declaring and calling Windows API routines. (For more information on Windows API routines, see Chapter 15, “Using API Calls to Extend the Power of Access.”)
Performing replication tasks. (For more information on replication, see Chapter 23, “Welcome to the World of Database Replication.”)
These are only of few of the tasks requiring the use of VBA.