When to Use Macros, When to use VBA ?

[LittleSmudge]

Those of us with very long memories will remember Access version 1 were any operation that you needed to automate required the writing of Macros - There as no Module Tab on the database window - No VBA option.

This wasn't a problem because we were all used to writing Macros in Excel etc and it seemed a natural progression ( well it did to me. )

Since Access version 2 I've gone over to VBA to do everything and don't use Macros at all now.

However, given MicroSoft tendency to dump out of date ( no longer recommended ) methods at the first opportunity I was wondering why Macros are still available ?

Is there ANYTHING that you can do in a Macro that can't be done in VBA code
Is there anything that is easier / quicker ( to write or execute ) in a Macro rather than VBA.

Are macros 'a thing of the past' or do they still have their place in a modern Access database development.


G LS

 

[sjcullis]

Man, you must want to start a long thread with a question like that! I've had so many arguments with collegues about this subject it's hard to count. Personally, I actually like using macros for the simple reason that they - when given appropriate indexing names - are more easy to reference after months away from a project.

I do use VBA where it seems to warrent it but not always, I like the simplicity and visibility of macros. And, yes, use of macros may slow performance but, in my experience, hardly by very much. I've never noticed a significant chnage in speed when comparing a code ran in a macro or VBA.

Horses for courses I guess, I know some guys that will not use macros just in principle because they feel less like programmers!

Steve

 

[petersdaniel]

Macros still serve as a good "quick tool" for doing simple object automation activities in Access. They are great tools for "lay people" who may want to put together a more sophisticated application without investing heavily in VBA knowledge.

Keep in mind that Access is not targeted solely at "developers", but also general office staff that may want to put together rudimentary applications without the aid of a developer. This is why form wizards, query wizards and table analyzers are abound in this product.

 

[idd]

I agree with Petersdaniel macros are just an easy way to automate things. When I first started off with Access back at university I was using macros for almost everything. Now I tend to use VBA.

Macros are easy to understand whereas VBA requires a heavy investment of time to learn. Like Petersdaniel said Access is not just for developers.

 

[cheerio]

The first great advantage of VBA is that code can be attached to objects such as forms and reports. This means that you can take a form from one database and export it to another and the code will go with it. It also means that with VBA you are not faced with the issue of which macros belong to which forms. For example, if you drop a redundant form can you safely drop all the macros it calls or are they perhaps called elsewhere.

The second great advantage of VBA is that you can add error handling. It may be acceptable for you to have a macro stop on a fault if you wrote it and you are running it. It is never acceptable if your project is going to be operated by other users.

In a sense you can have your cake and eat it. You can create a macro and test it. When it's working you can save it as VBA code, complete with error handling. This can be quite a good way for beginners to learn VBA and the object model, particularly as Access does not have a recorder.

It was the case that to reassign keys you needed to use a macro as no VBA alternative was available. I am unsure whether that is still true. I am not aware of anything else that cannot be done in VBA.

Ken

 

[JoeMiller]

I agree with Cheerio except for the fact that there is no way to run VBA at startup of the database. You must still resort to an AutoExec macro to begin running you VBA code. Other than that, there is no need for Macros because you can do everything else in VBA.

HTH

PS - Cheerio is still right about needing macros for SendKeys functions, but using SendKeys is not a smart idea ever as it is very error prone and buggy.

Joe Miller
joe.miller@flotech.net

 

[cheerio]

If I wanted VBA on startup I would create a form that was loaded on startup and put code into its load event. The form could hide itself if necessary.

Ken

 

[krsherm]

With the notable exception of AutoExec, those who can, code; those who can't, write macros.

Rock On!

Kevin

 

[JoeMiller]

While you can use the form load, it's less memory and processor intensive to use an AutoExec macro. Us performance junkies are a crazy bunch!

Joe Miller
joe.miller@flotech.net

 

[cheerio]

Some people find it helpful to load a form on startup and leave it hidden while the application runs.

If the user tries to exit other than through the application menus, Access will try to unload the form and trigger an event that can be trapped. This can ensure that any necessary tidying up is done.

If you are going to have such a form anyway then there is no reason not to use it for a startup process. If not then the macro method is fine.

Ken

 

[MichaelRed]

No! No!! NO!!! MACRO!!!!

(o.k. I'll get off of the soap box)

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[Junior1544]

Thank you MichaelRed...

I agree with Michael that Macro's are a pretty big No No...

VBA is much faster (i believe that was said above), and with code you can do any thing that can be done with a macro... In my app's I always have a splash screen so any code can be run from the on load of that...

Macro's are still there primarily for the non-developer/office people that use the software... they are a nice quick tool for them. But for profesional app's, vba is the way to go...

Just my opinions...

--James
junior1544@jmjpc.net
Life is change. To deny change is to deny life.

 

[pvted]

Another reason to use VBA rather than macros is that macros do not work in the Access Runtime environment. The Access Runtime environment is great way to deploy an Access program to users who do not have (or need) the full program installed on their computer.