Hi Kevin,

If you capture to the file and look into the variables and values you will notice that variables that are deeper in call stack have method/procedure listed after the value, ie.

Variable Scope Type Value Procedure Name
SCLASS Local C "_editor" new_editor

Procedure name for methods contains only method name not full path to the object where it comes from. Variables are listed in their order of creation. It wouldn't be to hard to write parser and get variables reviewed together with callstack information.
HTH.

BR,
Tomislav


>DISPLAY MEMORY only captures variables for the current
>procedure you're in.
>
>If the procedure throws an error and transfers control to
>an ON ERROR routine, then the only variables availble that
>DISPLAY MEMORY sees are those in scope in the ON ERROR routine.
>
>
>>Kevin,
>>
>>I am using DISPLAY MEMORY catpured to a file.
>>HTH.
>>
>>
>>>The problem is that if procedure 'A' throws an error which
>>>triggers the ON ERROR routine, there is no way to
>>>know what the value of the variables in the offending procedure
>>>are.
>>>
>>>Any thoughts on this?
>>>
>>>
>>>
>>>>No.
>>>>
>>>>>Is there any way to navigate back up through the call stack to retrieve variable values for error logging?
>>>>>
>>>>>The LIST MEMORY command only shows public variables and variables local to the error handler routine,
>>>>>so I cannot see the contents of variables in the function that triggered the ON ERROR.