Re: Function call string [message #90758 is a reply to message #90756] |
Thu, 09 April 2015 22:30   |
penteado
Messages: 866 Registered: February 2018
|
Senior Member Administrator |
|
|
Hello,
One way, not necessarily a good way, is to use the help output:
pro functioncallstring,arg1,arg2,key1=key1,key2=key2
help,/recall,output=o
print,o[1]
end
So that when calling it the result would be
IDL> functioncallstring,10*!dpi,cos([1d0,-1d0]),key1='some '+'string'
1 functioncallstring,10*!dpi,cos([1d0,-1d0]),key1='some '+'string'
I can see some caveats:
1) The usual warning about using help's output:
"Note: The OUTPUT keyword is primarily for use in capturing HELP output in order to display it someplace else, such as in a text widget. This keyword is not intended to be used in obtaining programmatic information about the IDL session, and is formatted to be human readable. The format and content of this text is not guaranteed to remain static from release to release and may change at any time, without warning."
(http://www.exelisvis.com/docs/HELP.html#H_835179117_832171)
2) This would only show how this procedure was called from the command line, because it is just showing the last command typed on the console. If you are looking to how the procedure was called from some other procedure, this will fail.
On Thursday, April 9, 2015 at 5:20:11 PM UTC-3, Gordon Farquharson wrote:
> Is there a way to access the string that was used to call a function or procedure in IDL? For example, lets say I call:
>
> display, 'A carrot is orange'
>
> Is there a way to access the string "display, 'A carrot is orange'" from within the display procedure?
>
> The reason I'd like to do this is that I'd like to record how a function or procedure was called in the meta data that the function or procedure generates, so that it is easy to make the same call again in the future.
>
> (I seem to recall that there was a discussion on this topic previously, but I can't find the thread.)
>
> I realize that I could construct the function call string from the arguments, but the output is not generic or pretty because one has to decide on things like how many decimal places to use to represent floating point values, and one has to take care of each keyword setting.
>
> Maybe a better self-documenting way to do this is to have a configuration file, e.g., an XML file that the procedure or function reads, and that accompanies the output. While I have done this previously for other routines, it seems a little overkill for my current application. Maybe it is the best solution though.
>
> (Not sure if David is still posting tips for his web page, but this would be a cool one to add if there is a neat solution. Maybe he already has it there.)
>
> Gordon
|
|
|