Macros versus VB Code

[Joe Wroblewski]

Is there any reason to use macros versus VB code?

Will speed be affected? How about memory usage?

I'm a relative novice, but I do know how to save a macro as code.

 

[Douglas J. Steele]

There are no advantages that I'm aware of to using Macros vs. VBA code, and
there are certainly disadvantages (the lack of error handling being the
major one)

 

[Marshall Barton]

Is there any reason to use macros versus VB code?

Will speed be affected? How about memory usage?

I'm a relative novice, but I do know how to save a macro as code.

Macros might be easier to use when you
are just getting started, but there is quite a bit of
functionality that macros just can't provide. Macros are
also missing or sorely lacking features that are essential
in anything more than a trivial application: error handling,
sufficient commentary, search/replace, a host of debugging
options and the ability to print out a listing.

If you're going to be working on anything beyond simple slap
it together databases, you really have to know VBA.

I've only ever used two macros in my programs, AutoKeys and
AutoExec.

 

[John Vinson]

Is there any reason to use macros versus VB code?

Will speed be affected? How about memory usage?

I'm a relative novice, but I do know how to save a macro as code.

Just to agree with Marshall and Douglas: macros have very limited
capabilities and VBA is much to be preferred. But just to add - while
it's possible to convert a macro to code, you won't necessarily get
GOOD code. The conversion utility will slavishly replicate the macro
structure, which must work step by step, doesn't allow variables or
looping, etc.; often the converted code can be cleaned up and
simplified a great deal.

 

[Bas Cost Budde]

Is there any reason to use macros versus VB code?

Will speed be affected? How about memory usage?

I'm a relative novice, but I do know how to save a macro as code.

Somebody mentioned the ability of passing parameters yet? No. Macros do
not take parameters, code can. I couldn't live without parameters (and
don't you use public variables for that!)

 

[Joe Fallon]

Marsh,
Don't forget the very handy command line parameter:
/x MacroName

This allows you to set up a scheduled event that only needs the command line
to start Access, open the .mdb and run the macro.

Naturally the macro itself just calls RunCode and a VBA function.
So you can run just about anything.

 

[Marshall Barton]

Marsh,
Don't forget the very handy command line parameter:
/x MacroName

This allows you to set up a scheduled event that only needs the command line
to start Access, open the .mdb and run the macro.

Naturally the macro itself just calls RunCode and a VBA function.
So you can run just about anything.

Ok, Joe, I won't forget it. ;-)

While I can envision where /X could be very useful, I've
just never had occasion to include it in an app.

And, Yes, I should also have mentioned that that kind of
macro (and AutoExec) should never have more than one action.