6 replies to this topic

[calebsg]

Is there a system variable that will reliably return the name of the function that ran the global_lscall to pull up the current global window? I could put in a parameter but was wondering if I could skip a step.

TIA
Caleb

[Anthony Hood]

You should be able to use @FUNCT to identify the calling function

[Wim Soutendijk]

But if you call a global function from another global function, @FUNCT won't help you....

[Phil]

But if you call a global function from another global function, @FUNCT won't help you....

But he didn't say that

[calebsg]

Well I guess that's why I'm asking the question -- is there anything that is reliable to return the function that actually houses the GLOBAL_LSCALL? Regardless of whether it is a global or not.

Thanks again,
Caleb

[fuentevilla]

Try @CURFUNCT, it used to work in PRO-IV 4.6, I don't know if it's going to work with PRO-IV 5.5

[Chris Mackenzie]

Try @CURFUNCT, it used to work in PRO-IV 4.6, I don't know if it's going to work with PRO-IV 5.5

Obviously @CURFUNCT will only show the current global
function not the caller.

@FUNCT will contain the current MAIN function i.e. non-global.
But if your global is called from another global you will still
only see the current MAIN function.

To trace global call stack you can introduce global logic
in every function in and out logic to maintain a stack
which you can query via another global logic and global
function.