I found the documentation on the MACRO command potentially misleading (both in the PDF and the .CHM reference) :-
For macros that appear in Macro Scheduler's control panel, add '.scp' to the end of the macro name.
I have no idea what was intended by the "control panel" reference ... does not appear to make a difference at all.
Here's my attempt at making it clearer ...
1. ... If the macro name begins with a drive letter, it is assumed to be a fully-qualified pathname, including a ".scp" suffix.
2. ... If the macro name does not begin with a drive letter :-
- the Macro Scheduler installation folder is added as a prefix.
- the ".scp" suffix is added if not already present.
Examples as "proof" ...
Macro @SubMacro has a single line (MessageModal command)
Macro @SubMacro is located ... "C:\Macro Scheduler\Testing\@SubMacro.scp"
Macro @SubMacro is listed in the same MSched macro listing group display as @Calling macro
( ... Group is "Testing" )
Macro @External has a single line display and resides in "C:\Macro Scheduler\@External.scp"
Macro @External does not appear in MSched's macro display list (i.e. not in macros.dat)
.
Macro @Calling is located ... "C:\Macro Scheduler\Testing\@Calling.scp"
Macro @Calling.scp exists has the following lines :-
// Invalid Calls
1....Macro>@SubMacro
2....Macro>@SubMacro.scp
3....Macro>C:\Macro Scheduler\Testing\@SubMacro
4....Macro>C:\Macro Scheduler\@Unlisted
...... // Valid Calls
.......Macro>Testing\@SubMacro
.......Macro>Testing\@SubMacro.scp
.......Macro>C:\Macro Scheduler\Testing\@SubMacro.scp
.......Macro>@Unlisted
.......Macro>@Unlisted.scp
.......Macro>C:\Macro Scheduler\@Unlisted.scp
When run ... macro @Calling responses are as follows :-
Line 1: Macro, C:\Macro Scheduler\@SubMacro.scp, specified in Macro> command Does Not Exist
Line 2: Macro, @SubMacro.scp, specified in Macro> command Does Not Exist
Line 3: Macro, C:\Macro Scheduler\C:\Macro Scheduler\Testing\@SubMacro.scp, specified in Macro> command Does Not Exist
Line 4: Macro, C:\Macro Scheduler\C:\Macro Scheduler\@Unlisted.scp, specified in Macro> command Does Not Exist
The remaining lines all work correctly.
Changing MSched display to "All Macros" doesn't change anything.
The current (Windows Explorer) folder at the time was "C:\"
Hope this helps someone.
Robin.
MACRO command documentation
Moderators: Dorian (MJT support), JRL
-
- Junior Coder
- Posts: 49
- Joined: Fri Oct 15, 2004 8:42 am
- Location: Johannesburg, South Africa
-
- Junior Coder
- Posts: 49
- Joined: Fri Oct 15, 2004 8:42 am
- Location: Johannesburg, South Africa
I'm just curious ...
... about the requirement for hardcoding the called macro location.
Documentation mentions this became necessary so that the macro Compiler could locate the called macro.
Msched itself "keeps track" of the location via macro group properties.
(The macro group has the folder/subfolder location)
The same methodology could have been used by the compiler to find out where the macro was located.
Was it simply so that "unlisted" macros could also be compiled ?
Documentation mentions this became necessary so that the macro Compiler could locate the called macro.
Msched itself "keeps track" of the location via macro group properties.
(The macro group has the folder/subfolder location)
The same methodology could have been used by the compiler to find out where the macro was located.
Was it simply so that "unlisted" macros could also be compiled ?
The compiler is a separate entity. It doesn't know anything about other files. All it does is compile the script in question. Therefore it is better for the Macro command to address a macro by it's path and filename. It is generic and will work whether compiled or not.
Easiest thing to do if the macro you are calling is in the same directory as the one you are calling from use the SCRIPT_DIR variable:
Macro>%SCRIPT_DIR%\macroname.scp
Then you can't go wrong if you distribute macros in the same folder or compile it and provide with the scripts in the same location.
Easiest thing to do if the macro you are calling is in the same directory as the one you are calling from use the SCRIPT_DIR variable:
Macro>%SCRIPT_DIR%\macroname.scp
Then you can't go wrong if you distribute macros in the same folder or compile it and provide with the scripts in the same location.
MJT Net Support
[email protected]
[email protected]
-
- Junior Coder
- Posts: 49
- Joined: Fri Oct 15, 2004 8:42 am
- Location: Johannesburg, South Africa
Documentation still not updated
Version 7.3.11.1 this sentence still appears in the MACRO help :-
"... For macros that appear in Macro Scheduler's control panel, add '.scp' to the end of the macro name. ..."
What does this mean ? (What is this "control panel" referred to ?)
I am still hoping that it would oneday mean .... " if the macro is listed in MSched MACROS.DAT file". Maybe I'm dreaming
"... For macros that appear in Macro Scheduler's control panel, add '.scp' to the end of the macro name. ..."
What does this mean ? (What is this "control panel" referred to ?)
I am still hoping that it would oneday mean .... " if the macro is listed in MSched MACROS.DAT file". Maybe I'm dreaming
It does. by "Macro Scheduler's Control Panel" we mean Macro Scheduler itself. So that means it will be in macros.dat. However, you may still need to consider it's path as the current directory may change. As mentioned in a previous post if the .scp file is in the same location as the calling script the following will always work:
Macro>%SCRIPT_DIR%\macroname.scp
Macro>%SCRIPT_DIR%\macroname.scp
MJT Net Support
[email protected]
[email protected]
-
- Junior Coder
- Posts: 49
- Joined: Fri Oct 15, 2004 8:42 am
- Location: Johannesburg, South Africa
Yours vs Mine.
Sadly my version of MSched exhibits completely different behaviour to yours.
My original post refers .... please see the list of valid and invalid calls
Macro @SubMacro appears in macros.dat in a group.
Physical location is in a subfolder under MSched install folder. @SubMacro.scp
[Answer: Because it is not in the MSched install folder ... adding .scp to the macro name does not do anything. ]
For the macro to work ...
Macro>Testing\@SubMacro
The ".scp" suffix is absent and it works. Yet according to your doc it should not.
Same goes for this one ... also works
Macro>C:\Macro Scheduler\Testing\@SubMacro
Semantics, you may say.
But that was why I posted the original suggested correction.
My original post refers .... please see the list of valid and invalid calls
Macro @SubMacro appears in macros.dat in a group.
Physical location is in a subfolder under MSched install folder. @SubMacro.scp
[Answer: Because it is not in the MSched install folder ... adding .scp to the macro name does not do anything. ]
For the macro to work ...
Macro>Testing\@SubMacro
The ".scp" suffix is absent and it works. Yet according to your doc it should not.
Same goes for this one ... also works
Macro>C:\Macro Scheduler\Testing\@SubMacro
Semantics, you may say.
But that was why I posted the original suggested correction.
I do keep saying that you need to consider the path and have now twice suggested that for macros in the same location as the calling macro the easiest solution is just to do this:
Macro>%SCRIPT_DIR%\macroname.scp
We are all saying the same things here. I concede that the documentation needs updating. It was written when all macros were always stored in the same location and indeed it is still the case that the default location for all macros is the same. Now that macro groups allow macro locations to differ I would agree that the documentation can be updated to indicate that the path is necessary. I will ensure that the documentation is amended for the next release. However, it does already say "It is also advisable to specify the full path should the path change during the execution of the calling macro."
Macro>%SCRIPT_DIR%\macroname.scp
We are all saying the same things here. I concede that the documentation needs updating. It was written when all macros were always stored in the same location and indeed it is still the case that the default location for all macros is the same. Now that macro groups allow macro locations to differ I would agree that the documentation can be updated to indicate that the path is necessary. I will ensure that the documentation is amended for the next release. However, it does already say "It is also advisable to specify the full path should the path change during the execution of the calling macro."
MJT Net Support
[email protected]
[email protected]