Macros (vs VBA)

[NJD]

I'm quite experience with VBA, working with both Excel and Access.
However, I've had almost no exposure to Access macros. I was taught to
use VBA instead.

Now I've been brought in on a project where the entire application is
coded in macros.

I can read them for the most part.

My first inclination is to advise my employer that this application
should be converted to VBA before making major enhancements. Does that
seem reasonable to you folks?

I don't know if I want to get overly involved in a mixed model. Seems
to messy. The macros also seem obsolete to me, but maybe that's just
because I'm so used to VBA.

Any thoughts?

 

[Paul Overway]

You are right to question the use of macros. No one in their right mind
would distribute an application coded using macros.

1. No error handling
2. No documentation (i.e., code comments)
3. Less functionality/ability

Because of these issues, any macro developed application will be limited in
usefullness to all but the person who developed it. Its use will be avoided
or it will be quickly discarded. These issues are especially problematic
if the application is used in an Access run-time environment because the
lack of error handling will crash the app.

 

[John Vinson]

I'm quite experience with VBA, working with both Excel and Access.
However, I've had almost no exposure to Access macros. I was taught to
use VBA instead.

So you know that an Excel "Macro" is much closer to an Access VBA
Module than it is to an Access Macro...

Now I've been brought in on a project where the entire application is
coded in macros.

Eeeuwwwww.... yuck.

I can read them for the most part.
:-{/

My first inclination is to advise my employer that this application
should be converted to VBA before making major enhancements. Does that
seem reasonable to you folks?
Very.

I don't know if I want to get overly involved in a mixed model. Seems
to messy. The macros also seem obsolete to me, but maybe that's just
because I'm so used to VBA.

I'm with you. Convert to VBA or even avoid this application
altogether.

I've converted macro-based apps to VBA; there is a tool to convert a
Macro to VBA, but it's not useful IMO - it does a very literal, line
by line translation, keeping the logical structure of the macro
instead of using looping or any real code features. I'd suggest just
reading the macro (or watching it work, or - faint hope here indeed! -
reading the documentation) and replicating the functionality of the
macro from scratch.

Good luck. This is a chore.

 

[Albert D. Kallal]

Like everything, we don't always get handed a perfectly written application
to
develop, or maintain.

So, I guess the real question should you try and "remove" the existing
macros, or simply work around them...

My bets are on the 2nd approach. Stuff that works..just leave it alone. For
new stuff, or new event code etc, then you can simply use VBA.

So, no..the mixed model is not such a enemy. And, if you make lots of
enhancements...then you will simply re-write the macros as vb code. This is
called refactoring code.

There is really not a lot of reason to re-write stuff that works perfectly
well now. In fact, re-writing of existing working stuff means you will
likely
introduce bugs. Any gains made by having a better application development
tools like (VBA) will likely not offset the fact that current stuff works.

I would only re-write the macros when you HAVE TO modify the code, or the
form(s) in question. If, at the end of the project you have extra time left,
then I would certainly consider re-writing any macro stuff that works
perfect, but was not changed as a result of you modifying existing stuff.

 

[Ken Snell]

I would only re-write the macros when you HAVE TO modify the code, or the
form(s) in question. If, at the end of the project you have extra time left,
then I would certainly consider re-writing any macro stuff that works
perfect, but was not changed as a result of you modifying existing stuff.

Hear hear! I agree.

 

[Steve Schapel]

Hear hear! I agree.

Me too

 

[Arvin Meyer]

I'm going to have to agree with Albert on this. I have worked on many
applications which the original "developer" used macros. For the most part,
they work fine and I just code new functionality.

Ten years ago I once created a simple application using mostly macros as a
quick and dirty sample. Although it now has some code in it, they are still
using that app. They have resisted any effort to code a more robust
solution, mostly because it hasn't broken in all that time.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[NJD]

My bets are on the 2nd approach. Stuff that works..just leave it alone. For
new stuff, or new event code etc, then you can simply use VBA.

Makes sense. This will be my approach. Thanks Albert and everyone.

--Nick

 

[Albert D. Kallal]

Interesting.....I wondering if all you folks have read Joel's article on
this issue?

http://www.joelonsoftware.com/articles/fog0000000069.html