Hi,
I've created a macro with several Sub-procedures, but i can't remember how to tell Visual Basic to start always in 'Main' and not in anyother one.
Any idea??
Regards.
Hi,
I've created a macro with several Sub-procedures, but i can't remember how to tell Visual Basic to start always in 'Main' and not in anyother one.
Any idea??
Regards.
How are you running this macro? Try putting the main in the last i.e. make it the bottom most sub and check.
Hi Deepak,
I'm running it from the normal macro toolbox, I think I've the solution. When I save the macro, before close it, the 'Main' Subprocedure has to be selected.
you can try it, the macro is attach to first question.
Regards.
Marcos Rodríguez wrote:
I'm running it from the normal macro toolbox
Why not set a macro button and set your required sub in that. This saves timing in browsing the macro and also run the correct sub
Don't know how to do that, could you send me a link or explain it a little bit further, please?
Cheers.
Marcos Rodríguez wrote:
Don't know how to do that, could you send me a link or explain it a little bit further, please?
Marcos Rodríguez wrote:
Hi Deepak,
I'm running it from the normal macro toolbox, I think I've the solution. When I save the macro, before close it, the 'Main' Subprocedure has to be selected.
you can try it, the macro is attach to first question.
Regards.
A robust method (IMHO) is to make your subs have arguments. You don't have to actually use them, and you can even make them optional. The macro will not start with any sub that takes an argument (optional or not)
sub main()
'do some stuff
Call SomeOtherSubThatDoesntNeedArguments
'OK now do more stuff
end sub
sub SomeOtherSubThatDoesntNeedArguments(Optional DummyArgumentAnyway as Boolean)
'this sub's code
end sub
Hi Josh,
Thanks, I'd just realized of that, I had to introduce a fake argument .
Cheers
You can look at another option suggested by Solid Air at this post: Running my macro from the start-screen starts with wrong module/sub
Artem Taturevych wrote:
You can look at another option suggested by Solid Air at this post: Running my macro from the start-screen starts with wrong module/sub
Yes, the inimitable Deepak actually had that one right out the gate... Although I think you mentioned that sometimes it seems not to work. I see you mentioned the dummy arguments... Not sure how C # works, but with VBA if you make the dummy variable optional then you don't actually have to use it when you call the function... Only the declaration of the sub is different.
Yes, I was sure it didn't work for older sw versions, but I have done some tests for SW 2017 and SW 2018 and found that this is always the last parameterless method of the last module (I do not have old SW versions anymore so cannot test there: perhaps this was a behaviour of VBA6 and it changed when they switched to VBA7 or perhaps I was just wrong and it always behaved this way - not sure). Basically when you edit the macro you will have a cursor on this method. I didn't managed to break this behaviour so I assume Solid Air was right in his findings. I still not fully like this approach as it doesn't look 'rock solid' to me. I still prefer dummy parameter. BTW. Great idea with optional dummy parameter for VBA macro!
A robust method (IMHO) is to make your subs have arguments. You don't have to actually use them, and you can even make them optional. The macro will not start with any sub that takes an argument (optional or not)
sub main()
'do some stuff
Call SomeOtherSubThatDoesntNeedArguments
'OK now do more stuff
end sub
sub SomeOtherSubThatDoesntNeedArguments(Optional DummyArgumentAnyway as Boolean)
'this sub's code
end sub