Autocall macros - Parameter descriptions, Compiling without executing

[Brian]

Hi all

I am interested in showing the inline descriptions for parameters used by my autocall macros. (i.e. To add a description for PARAM_NAME, add an inline comment after the parameter). I understand these descriptions aren't shown unless the macro has been compiled. Is there a way to compile all or some autocall macros stored as .sas files in an autocall folder without executing them or feeding them any parameter values?

Example:

autocallmacro.sas

%macro autocallmacro(parameter /*First parameter*/);

%mend;

SASEG:

     %autocallmacro(

Autocall macro(Name)

Name:

First Name

I'm using the following code to:

/*Enable the autocall library:*/

     options mautosource mrecall sasautos = ("C:\AutocallLibrary\" sasautos);

/*List all macros currently defined in work.sasmacr:*/

proc catalog catalog = work.sasmacr;

     contents out = work.list;

quit;

/*Clear out all macros currently defined in the work.sasmacr (Note: Used for developing/debugging autocall macros):*/

proc catalog catolog = work.sasmcr et=macro kill force;

run;

Any thoughts?

Thanks for your help in advance!

[ballardw]

The %include statment will submit any SAS code referenced. If the file only contains a macro definition such as those in in autocall libraries then they would compile but not execute.

Assign a filename with wildcard to the loction of the macros:

filename test "C:\path\*.sas";

%include test;

for windows as an example. NOTE: ALL sas programs in the location will be executed so you want to segregate the macros or have a standard naming convention like Mac_*.SAS would find.

[Brian]

Thanks for your reply! The %include helps re-compile all of the macros in the autocall library as you stated. Any thoughts on the inline comments? %include isn't pulling inline comments for the macro parameters.

[ballardw]

From your first post it looks like you may be doing something with Enterprise Guide. I don't use that and so can't help with that part.

[Tom]

I suspect that EG is using the %COPY statement to pull the source of the macro to enable the display of inline descriptors.

To store the macro source code so that it is available for %copy command to pull the source you need to do at least.

1) Set the MSTORED option

2) Set the SASMSTORE option to the library were you want them stored.

3) Add the /store source to the end of all of your %macro statements.

I am not sure how this mode of storing compiled macros into catalogs conflicts with the traditional autocall process you have been using.

[jakarman]

Agree with ballardw, it is about configuring Eguide. Would be an option to redirect this discussion in the Eguide discussions.
ChrisH is following that one.

[ChrisHemedinger]

Hi folks -- this thread was just brought to my attention.  Actually the answer is more straightforward (and unfortunately more limited) than what has been discussed so far.

The parameter descriptions are parsed out of the macro declaration (the %macro statement), so unless the %macro is defined in the same program where you are using the macro, you won't see the help displayed in the SAS Enterprise Guide editor.

You might be able to "trick" the program editor into displaying the help by including a dummy declaration of the macro at the top, and then somehow %include or otherwise redirect SAS to find the actual macro somewhere else during runtime.  But I'm not sure that this helps your scenario.

Another technique that might prove more useful is to define editor abbreviations for commonly used code segments (such as macro calls) that also contain placeholders for the information you need to fill in.

Chris

[Peter_C]

Brian

The last technique that Chris suggests

to define editor abbreviations for commonly used code segments (such as macro calls) ... contain placeholders 

points to a solution in line with your image in the original posting.

     %autocallmacro(

Autocall macro(Name)

Name:

First Name

Depending on the number of macros involved, creating a library of corresponding editor abbreviations might be worthwhile. A large library means quite a lot of work.

There is a trade-off between supporting users who encounter common macros for the first time, and supporting the rarely used macros where all users are unfamiliar.

best of luck

peterC

[Brian]

Hi all

Thanks everyone for your suggestions.

For inline descriptions, the dummy macro declaration at the top works as long as it’s written within the same program.  The inline descriptions do not work in a separate program even if it is in the same project. If the inline descriptions were applicable across all programs within a project, you could potentially add a dummy macro declaration program to the project and run it separately.

The abbreviations are great for your own use but I understand you need to import/export these abbreviations in the GUI when sharing them. You aren’t able to attach them to a project file or link to them in a shared location.

It would be helpful if AUTOCALL macro libraries and %INCLUDE could incorporate directly all functionality of a regular macro declaration including inline descriptions. As well, the ability to link to external abbreviation libraries would be helpful - You could limit your project to only the related abbreviation libraries as needed.

Brian

[mbuchecker]

Hi Chris,

I know this thread is a few years old, but it looks like the functionality is still the same. Are there plans to improve this functionality to add the customized inline help for parameter descriptions on the calls to the macro for autocall macros?  I'll even take already compiled macros (ie: you call the macro once and then you get the parameter descriptions for the next call).

The workarounds are pretty cumbersome if you have many autocall macros.

Thanks!