Advantages of Module vs Macro?

[Skip Bisconer]

Is there an advantage one way or the other to converting Macro's to Class Modules?

 

[ajetrumpet]

Skip,

I would think logically, that since Macros are just pre-recorded instructions to the program, converting them would save a bit a memory usage, especially if you are using a lot of them (but this is just a guess). I am just thinking of all the "calling" the program has to do when you want a macro to run. I would think that writing the commands in Visual Basic would keep them all in the same place, and in a "guided" environment, rather than jumping back and forth between recorded instructions and your instructions.

Remember too, that when you convert Macros to code, Access writes a huge amount of unnecessary crap in the module that you are welcome to delete.

 

[Skip Bisconer]

Thanks for the info. Adam

 

[ajetrumpet]

Hey man, it's almost two cents worth, but I'd only give it 1 today.

 

[Simon_MT]

To put it mildly, I would always go for Modules.

I only have lightweight forms and reports i.e. no Sub routines everything is in a Module.

There is a feature within the conversion that adds:

With CodeContextObject

This means that when referring to the Object launching the code it does not have to be referred to explicitly, a dot will do.

The are more technical reasons for using VB but taking your current standpoint I would just go for it.

It does mean that there will be numerous changes to the events calling a Function rather than a Macro but it is still worth the effort.

You will never look back.

Simon

 

[gemma-the-husky]

personally

modules every time

ther only things you need macros for are autokeys macros and autoexec macro

everything else imo is best done in code - i think most experienced devleopers here would tend to go with code

 

[tehNellie]

Another vote for using code over macros.

There is a reason why one of my database appliactions never quite makes it into the development cycle. it's all written in macros, there's no documentation and whoever wrote it initially never bothered to rename the various controls on the forms. Trying to decipher what an application written in macros does is a right pita at the best of times, this makes it nigh on impossible.

 

[RuralGuy]

There is also *no* error handling in a macro!

 

[ajetrumpet]

i think most experienced devleopers here would tend to go with code

That's probably because an experienced developer can write a macro command faster than he/she can find the "create macro" button.

 

[tehNellie]

Not to mention read and understand 100 lines of badly written VBA easier than figure out what that 4 line macro is doing.

 

[Skip Bisconer]

Thanks everyone best opinions in my point of view are the ones doing it. This input is quite valuable to me.

 

[boblarson]

There is also *no* error handling in a macro!

EXCEPT in Access 2007, which DOES have error handling in macros...

But I prefer code over macros as well.

 

[ajetrumpet]

Thanks everyone best opinions in my point of view are the ones doing it. This input is quite valuable to me.

I don't do it, but I know a tiny bit about it.

 

[GPGeorge]

It's not just about the lack of error handling (pre-2007) and the ability to see what the code does in the VBA module. It's about a much greater flexibility and power available to you in VBA. Anything that you can do with a macro can be done in VBA, but the reverse is NOT true.

FWIWI: Until 2007 came along, I hadn't written a macro in 10 years or more.

 

[boblarson]

It's not just about the lack of error handling (pre-2007) and the ability to see what the code does in the VBA module. It's about a much greater flexibility and power available to you in VBA. Anything that you can do with a macro can be done in VBA, but the reverse is NOT true.

Amen to that!

Interesting to see you here George! I guess it is kind of funny how you came for a visit, eh? (UA hilarilty)