Freigeben über

Embedded Macros

  • Artikel

As I mentioned on this post, macros are the way to go when running in disabled mode or when you want to do basic things without having to write any piece of code.

In Access 2007, we are adding a new twist to macros. We now allow macros to be saved with the form, report or control, directly in the event property. These streamed macros are called Embedded Macros.

Embedded macros are very handy as they allow you to add some quick codeless functionality to your objects without creating actual macro objects all over the place. Even further, as embedded macros live within controls/form/reports, so you can copy and paste them and the macros will go along with them, which is very helpful when authoring a lot of controls that have very similar functionality.

Even further, embedded macros have name fixup hooked up, so as you rename the forms and reports it references, the embedded macros are fixed up correctly as other form/report/control properties (such as the record source) are. This makes it much simpler to add some snipets of logic to do what you want as you develop.

So when should you use embedded macros vs. standalone macros?

Generally speaking, embedded macros are ideal when you add buttons and event handler to open forms/reports on click, apply filters and/or search for data in records (I'll cover this in a future post). With name fixup, all this should just work for good. For some centralized and shared macro functionality, standalone macros are the way to go - particularly as you can call standalone macros from embedded macros using the RunMacro action.

On my next post, I'll talk about error handling and some major improvements we made for macros.

Comments