Converting Macros to VBA code

[pbaldy]

You appeared to be directing your follow-up question to JoeM, but perhaps he isn't around. I read the response that suggested calling the code from a macro as his interpretation of what you wanted to do: "You want to run the VBA code you come up with from a Macro".



If that's not the case, you're certainly correct that calling it directly from VBA would be better than using a macro. Giving the function a different name than the macro isn't required, but it would avoid potential confusion.

Regarding "where is the source for Function MyCode()? In the navigation pane?", you would see the module the function is contained in, not the function itself. They can't have the same name.

[Lou_Reed]

Thanks very much for your quick reply. As far as naming the converted macro's VBA a different name well does the software do that when it starts off in the name of the code:

"Converted Macro"?

That is certainly a different name than the macro. The prefix "Converted Macro" sees to that.
And just keep the source in the navigation window? That is where the macro to VBA software put it.

Thanks for your reply.


Respectfully,

Lou Reed

[pbaldy]

The function will be named the same as the macro, and the module is named "Converted...". You're comparing the module name to the macro name, you should be comparing the function name, as that's what the suggestion referred to. A module can contain many functions. I just tested, and a macro named Macro1 was converted to a function with the same name: "Function Macro1()", in a module named "Converted Macro- Macro1"

I suppose it's personal preference, but if I converted macros to VBA, I'd copy the code elsewhere and delete the module named "Converted...". And as JoeM suggested, I wouldn't use the same name for the function, unless perhaps if the macro had a reasonably descriptive name AND I was deleting the macro. I wouldn't want 2 objects with the same name, even if Access allowed it.

[Lou_Reed]

In the zipped file that I attached is the db that I have been working on. The db crashes when I open it (see pdf files) and it is not clear why. I will go back and give the function a different name than the macro, but I do not think it is the reason the db crashes now when I open it.

The db just crashes and nothing more. I just need to know why.

Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[pbaldy]

See the problem (what the code calls vs what exists):

Form Heading - MAC
Form Heading-MAC

[Lou_Reed]

I saw that on early and I went back and corrected them all or so I thought; that was why it was so perplexing.

I will check again.

Thanks for your input.


Respectfully,


Lou Reed

[Lou_Reed]

Okay, I did as you suggested. Now I get another message. I am not sure what it is saying or even if it is an error.

The relevant files are attached.

Also, do you have an internet reference that explains the difference between function names and module names. It just seems confusing. I know the difference between file names and the names of subprograms in that file. I am assuming it is similar.


Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[pbaldy]

Having spaces (and symbols) in object names makes this type of thing more likely to happen. At a glance, you didn't notice that there were spaces in one and not the other.

[pbaldy]

I don't know of a good reference offhand. Basically the module is a bucket that holds subs and functions. You're always calling a sub or function by name, not the module that contains it.

The error is because your macro calls a function named "Form Heading _ MAC", which doesn't exist. There is one named "FormHeading".

[Lou_Reed]

Yes, I see your point. Then how do you call a function within a module and not avoid calling the module.

I am just taking what the macro to VBA translator did. I admit that I am screwing up names, but once that is done should not things work within the parameters of the macro to VBA translation?

Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[pbaldy]

Well, behind the scenes Access will load the module, but you don't worry about that, you just call the function. I might have a module named "basPublicFunctions" in my apps. There could be numerous functions in that module. Nowhere in my code will you see "basPublicFunctions", you'll just see the name of the particular function being called. That's why you can't have two functions with the same name, even if in different modules. The module name is irrelevant, it's just a bucket to hold the functions.

[Lou_Reed]

I went back and made sure all dashes were at mid-level - not too high and not to low. I also went back and changed any and all Form Heading-MAC to FormHeading-MAC. I even checked the RunCode command in the FormHeading-MAC. It still gives me the same error. This one defeats me.

Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[Lou_Reed]

I see your point (I think). I am not avoiding putting the VBA code somewhere else. I am going to, but where to put it? It is not associated with any form or it is associated with more than one form. If the function Form Heading is used in two (or more than one) different sets of code then do I put it in twice? That seems like what you are saying.

Is there some place that I can put it in and it is used by all?

Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[pbaldy]

Can't open the attachment right now, but try changing the RunCode to:

FormHeading()

In other words, use the name of a function that exists.

[pbaldy]

Is there some place that I can put it in and it is used by all?

They can be in any standard module. I typically have a module named "basPublicFunctions", or several of them grouped appropriately (basARFunctions, basReportFunctions, etc).