Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Access to local variables in calling procedure

volker_bock
Participant
0 Kudos

Hi there,

i know there is a trick to access at least global variables of the main program, without knowing them in the current context. This can be done via field symbols as this (actually I am in a BadI within stock determination in EWM):

  field-symbols: <fs> type any.

  ASSIGN ('(nameofprogram)variable') to <fs>

I would like to know, if there is a similar possibility to access also local variables from the calling routines. In my case, if I am in the debugging mode and select the calling routine/function module in the ABAP stack, I have access to it. Thus I believe it somehow must be possible.

Any ideas?

Volker Bock

1 ACCEPTED SOLUTION

ChristianGünter
Contributor

Hi Volker,

I fiddled a bit around and found out that the debugger uses the method IF_TPDA_CONTROL~GET_LOCALS of class CL_TPDA_CONTROL to get local variables.

Which does internally a C function call.

If you use this method in a custom program it throws an exception resulting in a shortdump.

Which indicates some issues in interprocess communication.

But perhaps someone will find a way to circumvent this obstacle.

Regards Christian

16 REPLIES 16

Former Member
0 Kudos

Hi Volker,

Not sure if I understood your scenario correctly.

But as per me local Variables gets refreshed from Memory when coming out of the context automatically.

I don't think accessing them is possible and even if you access them those won't be of any use as they won't contain any data in it.

R

ChristianGünter
Contributor

Hi Volker,

I fiddled a bit around and found out that the debugger uses the method IF_TPDA_CONTROL~GET_LOCALS of class CL_TPDA_CONTROL to get local variables.

Which does internally a C function call.

If you use this method in a custom program it throws an exception resulting in a shortdump.

Which indicates some issues in interprocess communication.

But perhaps someone will find a way to circumvent this obstacle.

Regards Christian

0 Kudos

I wish i could give you 100 pinots for this!

These kind of responses reinstate my faith in SCN ...

ipravir
Active Contributor
0 Kudos

Hi Volker,

i am not confirm with accessing a local variable, but there is  a Fm which provides field information of declared local structure.

FM Name:  GET_COMPONENT_LIST.

If you check the code behind, a C function called to get the Structure Information based on input program name and structure name.

  CALL 'AB_STRUC_INFO'

    ID 'PROGRAM'   FIELD PROGRAM

    ID 'STRUCNAME' FIELD FIELDNAME

    ID 'STRUCINFO' FIELD COMPONENTS-*SYS*.

Regards,

Praveer.

tomas_talpa
Active Contributor
0 Kudos

Not a real answer, Volker, just possible workaround -- since we have now implicit enhancements (nearly) everywhere, you can...

1st declare custom global variable in program from which you need the data (enh usually in some TOP include);

2nd move the local variable to this custom global one (enh where the local var is set);

3rd access the global variable via field symbols (as usual);

...the challenge is then around step no 2, to find the local place for impl.enhancement; but as they are at beginnings/ends of FMs & subroutines, it should be possible most of the time.

TomT

Clemenss
Active Contributor
0 Kudos

Hi Volker,

local variables in methods, form routines and function modules are created just the moment the processing starts.As soon as the END method, form, function is reached, the local variables are freed and returned to the memory stack.

So the only time you could possibly access the local varaiables is when the code is processed (as you can see in  debugger). So how do you expect to access local variables before or after they exist?

The only variables that will survive are static variables inside forms or methods. If you are interested in those, there might be a way...

Regards, Clemens

0 Kudos

Hi Clemens,

i think Volker means that he wants to go down the call stack and "inspect" local variables of any caller like you can do in the debugger. So the local variables are still available at that time but in another level of the call stack.

So the question is, if the debugger can do this kind of magic, can we do this in our programs too?

Regards Christian

0 Kudos

I dare to answer instead of Volker -- nobody is expecting "to access local variables before or after they exist", the idea is simply to access them from the very point in program flow where you see them in debugger.

In other words, you have breakpoint in UE and you see in debugger that somewhere higher in the call stack there are some local & global variables... but from program execution you can access only globals (via this <FS> trick, I'm not sure what is the proper name), not locals, although you clearly see in debugger so you know they exist somewhere... you just wants to access them.

Clemenss
Active Contributor
0 Kudos

Thanks folks,

you are right - I was just confused. Now I got it - but no solution at hand. I'm not too familar with the debugger architecture so I don't know what happens in detail when debug environment is created in old debugger. The new debugger controls the whole process and works definitely totally different.

What ever a solution would be, ist will be primarily of academic interest. Programmatically you may store a reference of a local variable in a container class and access it from wherever you need to.

Regards, Clemens

naimesh_patel
Active Contributor
0 Kudos

Local variables would not be visible to outside of that local subroutine, FM, Method etc.

In my case, if I am in the debugging mode and select the calling routine/function module in the ABAP stack, I have access to it

As you have noted, the local is only visible if you select that subroutine from the callstack.  To 's point, local is only visible if you select that program from callstack. Even debugger doesn't show them up if you don't have proper "context".

For your requirement, if you have access to explicit enhancement points before your BADI, you should be able to read the local variables provided it is already set with the value you are looking for. Create a static variable in your BADI implementation class and set that variable in the explicit enhancement implementation. Use that variable in your BADI implementation and clear it just before existing the BADI method.

Regards,
Naimesh Patel

0 Kudos

To Christian Guenter's point, local is only visible if you select that program from callstack.

Exactly. I thought that was obvious from the context.

0 Kudos

Good point about BADI's static variable, Naimesh -- that's easier & more elegant than my approach with global z-variable, saving one enhancement & this <(program)variable> trick (I'm bit confused how that might work if the BADI itself is defined somewhere else/later, but it's up to me to properly catch up with OO ABAP ).

Still, as for "if you have access to explicit enhancement point" -- why do you limit your approach to explicit enhancement? There is no difference whether the variable will be set-up form explicit or implicit enhancement.

0 Kudos

Unless you are in the context of the local subroutine, debugger will not be able to get that value. So, how debugger methods (IF_TPDA_CONTROL~GET_LOCALS of class CL_TPDA_CONTROL or any) would be able to read them outside (in the BADI implementation).

Thanks,
Naimesh Patel

0 Kudos
 why do you limit your approach to explicit enhancement?

Implicit would be only available at Beginning of the subroutine, and at the end of the subroutine. (I'm using the subroutine as an example, in which BADI is being called).

So, in the beginning implicit - the Variable is unknown  - as it is declared with DATA statement, after the Implicit enhancement.

And in the ending implicit - its too late. BADI is already called.

So, would need to have something like this for this to work:


FORM F_XYZ.

  data: lv_local_to_this type c.

ENHANCEMENT-POINT xyz SPOTS abc.

ENHANCEMENT-SECTION xyz_1 SPOTS abc.

  CALL BADI xyz_badi ..

ENDFORM.

I also don't like to use the field symbols to read the global memory.

Why NOT to use Field-Symbols to access Global Memory? - ABAP Help Blog

I would use the same enhancement, to pass even my global variables to the "Global" Static memory and use it in the down line calls.

Regards,
Naimesh Patel

0 Kudos

I don't know, that's the 1 million dollar question.

I brought this up just as an idea with the hope that someone knows how to do this properly and how to provide the proper "context" to these methods and get things working.

P.S.

To Christian Guenter's point, local is only visible if you select that program from callstack.


Exactly. I thought that was obvious from the context.

I thought you are referring to my other post, so sorry for messing up with the word "context"

Message was edited by: Christian Guenter

0 Kudos

So, in the beginning implicit - the Variable is unknown  - as it is declared with DATA statement, after the Implicit enhancement.

Yes, the variable is unknown at compile time. But at runtime you can access it dynamically with another field-symbol trick.

So something like this is possible.

This is possible due to the fact that in ABAP local variables are created when a subroutine/method is entered.

Validity and Visibility

For me this is just some kind of academic example. One should see this only as a last resort.

This is a very fragile approach, because at the next upgrade SAP might have refactored (renamed or removed) the lv_local_to_this variable and you would hardly detext this until it leads to logical errors during integration testing. But of course there are ways to detect this in the BADI method...