![]() |
Calling another macro?
Hi,
what's the diffrence between these two ways of calling another macro from within a macro? Call OtherMacro Application.Run "OtherMacro" Thanks, |
Calling another macro?
Application.Run would normally be used to call procedures with variables,
that is store the macro name in a variable as you process, or in another workbook. If the macro is in the same workbook, Call is far more efficient. You could even use Call if the macro is in another workbook, if you set a reference (ToolsReferences) to the other workbook in the calling workbook. -- __________________________________ HTH Bob "Charlotte E." wrote in message ... Hi, what's the diffrence between these two ways of calling another macro from within a macro? Call OtherMacro Application.Run "OtherMacro" Thanks, |
Calling another macro?
Hmmmm.....
I use 'Application.Run' because it is apparrently the only way to run macros in imported modules! Or is it? Is there any way to run macros in imported modules with 'Call'? Thanks, "Bob Phillips" skrev i en meddelelse ... Application.Run would normally be used to call procedures with variables, that is store the macro name in a variable as you process, or in another workbook. If the macro is in the same workbook, Call is far more efficient. You could even use Call if the macro is in another workbook, if you set a reference (ToolsReferences) to the other workbook in the calling workbook. -- __________________________________ HTH Bob "Charlotte E." wrote in message ... Hi, what's the diffrence between these two ways of calling another macro from within a macro? Call OtherMacro Application.Run "OtherMacro" Thanks, |
Calling another macro?
Okey, thanks - I'll stick to 'Application.Run' then :-)
"Nigel" skrev i en meddelelse ... If you have imported a module then it is part of the current workbook and is callable. If you are running code to import using VBE extensibility then probably not. -- Regards, Nigel "Charlotte E." wrote in message ... Hmmmm..... I use 'Application.Run' because it is apparrently the only way to run macros in imported modules! Or is it? Is there any way to run macros in imported modules with 'Call'? Thanks, "Bob Phillips" skrev i en meddelelse ... Application.Run would normally be used to call procedures with variables, that is store the macro name in a variable as you process, or in another workbook. If the macro is in the same workbook, Call is far more efficient. You could even use Call if the macro is in another workbook, if you set a reference (ToolsReferences) to the other workbook in the calling workbook. -- __________________________________ HTH Bob "Charlotte E." wrote in message ... Hi, what's the diffrence between these two ways of calling another macro from within a macro? Call OtherMacro Application.Run "OtherMacro" Thanks, |
Calling another macro?
That would be if you try and call that procedure directly, you would get a
compile error. IF you created a macro in another module that called the macro that gets imported, and call that from within the importing routine, no need for Application.Run. -- __________________________________ HTH Bob "Nigel" wrote in message ... If you have imported a module then it is part of the current workbook and is callable. If you are running code to import using VBE extensibility then probably not. -- Regards, Nigel "Charlotte E." wrote in message ... Hmmmm..... I use 'Application.Run' because it is apparrently the only way to run macros in imported modules! Or is it? Is there any way to run macros in imported modules with 'Call'? Thanks, "Bob Phillips" skrev i en meddelelse ... Application.Run would normally be used to call procedures with variables, that is store the macro name in a variable as you process, or in another workbook. If the macro is in the same workbook, Call is far more efficient. You could even use Call if the macro is in another workbook, if you set a reference (ToolsReferences) to the other workbook in the calling workbook. -- __________________________________ HTH Bob "Charlotte E." wrote in message ... Hi, what's the diffrence between these two ways of calling another macro from within a macro? Call OtherMacro Application.Run "OtherMacro" Thanks, |
Calling another macro?
Heh, heh - clever way to get around this lack of re-compiling option :-)
But to me it tends to be a little too much calling back and forward - I'll still stick to 'Application.Run', which gives a more direct approch... Let's hope that MS will allow re-compiling in future releases... Thanks for all your answers :-) "Bob Phillips" skrev i en meddelelse ... That would be if you try and call that procedure directly, you would get a compile error. IF you created a macro in another module that called the macro that gets imported, and call that from within the importing routine, no need for Application.Run. -- __________________________________ HTH Bob "Nigel" wrote in message ... If you have imported a module then it is part of the current workbook and is callable. If you are running code to import using VBE extensibility then probably not. -- Regards, Nigel "Charlotte E." wrote in message ... Hmmmm..... I use 'Application.Run' because it is apparrently the only way to run macros in imported modules! Or is it? Is there any way to run macros in imported modules with 'Call'? Thanks, "Bob Phillips" skrev i en meddelelse ... Application.Run would normally be used to call procedures with variables, that is store the macro name in a variable as you process, or in another workbook. If the macro is in the same workbook, Call is far more efficient. You could even use Call if the macro is in another workbook, if you set a reference (ToolsReferences) to the other workbook in the calling workbook. -- __________________________________ HTH Bob "Charlotte E." wrote in message ... Hi, what's the diffrence between these two ways of calling another macro from within a macro? Call OtherMacro Application.Run "OtherMacro" Thanks, |
Calling another macro?
Let's hope that MS will allow re-compiling in future releases...
Probably not going to be many more future releases of vba... vb is already gone... dotnet will be the future. Cliff Edwards |
All times are GMT +1. The time now is 12:25 AM. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
ExcelBanter.com