The New Macro Environment in Microsoft Access 2010
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One of the most radical changes in Access 2010 is the new macro development language and environment. Macros have come of age in Access 2010. I view this new macro environment as an automated interface to produce procedural code. The macro interface in previous versions was a menu driven way of creating automated tasks. It was very limited to automating simple tasks. Most Access developers disdained using macros because of its limitations. Writing VBA code was MUCH more flexible and not that much more difficult; especially with the use of Intellisense to prompt the user for parameters in a similar way to what the macro interface used.
Access has had a limited conditional capability for a few versions. Access 2007 added error trapping. In my opinion, using those features was beyond the Access end user for the most part. If someone was into using those tools, they were probably writing VBA code already. However, there was another improvement to macros in Access 2007 that did make them more valuable – the inclusion of embedded macros. Macros were now allowed to be embedded in a control’s event. The advantage of this feature was to make certain controls more reusable. A control with an embedded macro could be used on other forms and the code behind it would be included when the control was copied. This was not true of controls with VBA code behind them. When the control was copied the developer had to copy the VBA code as well. An example of this might be navigation buttons (First, Previous, Next, Last). Such buttons with embedded macros could be easily copied and pasted onto other forms; but this was still only good for simple macros because the macro language was still limited.
With Access 2010, I believe we have a much more useable macro language. While still not as comprehensive and flexible as VBA, it comes much closer. More importantly, a new type of macro has been introduced. In addition to UI (User interface) macros that can be called from and embedded into events on forms and reports, we now have Data macros as well. Data macros can be triggered by actions at the table level. Prior to Access 2010, the only way to execute some code was to place it behind a form or report event or to use a hot key driven macro. Now Access developers have a new tool to execute code (more on this later).
One other thing to know about macros is that they are required for automating forms published through Access Services. VBA code will not run within a browser window, but data and UI macros will. So, if you plan on linking your application to a Sharepoint server to Web-enable it, you will need to use macros to provide any level of automation.
Following is a screen shot of Access 2007’s Macro builder environment. In this environment the user selects an Action from a list of actions and then supplies properties of that Action. The list of Actions is pretty limited.
)
Next I’ve provided a screen shot of the Macro development environment in Access 2010. As you can see, you can select from a catalog of 70 Actions. You can either select from the pull down list in the editor window or from a catalog of Actions on the right side of the screen.
)
The advantage of using the Action Catalog is that you can search for an action without knowing the exact name. The search includes the name as well as the Description and Tool Tips. And when you highlight an action you can see a description of that Action.
)
A macro can be built by using selects from the Action drop down or the Action Catalog. When you choose an Action you get choices for that Action. For example, double clicking IF from the Program Flow listing produces the screen shown below. You can add a Conditional expression to test for (1). Or you can use the Expression Builder (2) to build your conditional expression. You can also add actions to perform if the condition is true from the pull down (3). Finally you can also use an Else or Else If for when the condition is false (4).
){kind=small}
Following is an example of a completed UI macro in Design View. A Conditional expression is entered (1). This macro shows a message box (2) indicating if there is or isn’t stock available to cover an order (note: this macro actually doesn’t work, I am just trying to illustrate a completed macro).
)
As I mentioned earlier, Access 2010 introduces Data macros. These macros are triggered by events that occur on tables. Such events fall into two basic categories: After Events and Before Events. Within these two categories are Data Blocks and then within Data Blocks are Actions that you can choose from. Before Events give you only one Data Block to work with – the LookupRecord Data Block. After Events add DataBlocks for CreateRecord, EditRecord, and ForEachRecord.
To build a Data macro, you need to open a table in either datasheet or Design mode. From Design mode you then select Create Data Macros from the Field, Record and Table Events section of the Table Design ribbon. As shown below.
){kind=small}
This pulls down the list of Events you can use. In Datasheet view, you use the Table ribbon to select the appropriate icon for the event you want to choose.
){kind=small}
Note that the Table ribbon also offers the ability to work with Named Macros. You can Create, Edit, Rename, or Delete Named macros from here.
)
Named macros can be used independently. They can be called from either UI or Data macros or from table, form, and report events. Named macros also have parameter properties that can make them more dynamic by passing information from the macro they are called from.
After choosing an event, the Macro Design mode opens. The difference in Macro Design mode is that the Actions catalog then offers a different set of Actions for UI macros. In fact, the catalog is different for After and Before macros. (See the following illustrations.)
)
)
Other than the Action catalog, Data Macros can be designed the same way as UI macros. You select Actions from the catalog or list. Data Macros function similarly to triggers in SQL Server. So this gives a whole other level of functionality for developers. An example of a data macro could be a situation where you add quantity for a product through a purchase. A data macro could be used to update back ordered transactions for that product and release them for completion.
I have to admit that I would greatly prefer if we could use VBA on both Web forms and native Access forms; but, I think the new macro functionality provided with Access 2010 will provide almost VBA-like capabilities. Developers can make hybrid applications that use forms with VBA functionality for local-based Access users and macro driven forms for Web-based users.