StackFrame

[TuringTest1]

dotnet provides a way cool StackFrame class that can be used to get Reflection information about the call stack, the methods and their parameters. however i don't see how to get the actual values of these parameters, for example the instance of the class defining a method on the call stack. is that because interpreting the actual data on the call stack is language dependent, or something like that? suppose i am a method and want to know the instance of the class calling me, can i do that? ((c'mon, no cheating by passing Sender as a parameter!!)) Tia. ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain!

[Colin Angus Mackay]

Why not pass sender as a parameter if your method needs that information? One obvious detail is that the callee may know nothing about the caller. For example, in a third party component that your program calls. The third party component won't know anything about your objects so what can it do with them? If it is all your own code then I think its time to step back and re-examine the design.

---

"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!

[Marc Clifton]

TuringTest1 wrote: suppose i am a method and want to know the instance of the class calling me OK, here goes. Obviously, the instance is available because, when using the debugger, you can click on the prior calls in the stack. That takes you to the caller code, and then you can inspect variables in that instance. However, what exactly would you do with the instance yourself? The way the debugger gets it is because the class instance is either stored in a CPU register or is somehow obtainable by inspecting the stack (I can't remember if "this" gets pushed or not). Anyways, it's just an address. The debugger is doing some magic by converting the pointer to a class. In C++, that's easy, but in C#, I'm not sure it's possible. Marc Microsoft MVP, Visual C# MyXaml MyXaml Blog

[TuringTest1]

Marc, Colin, thanks. Here is a brazen plug-- anyone reading this thread should read MyXaml-- it's way cool. Responding to Colin's question, if "sender" is only used in very odd cases i want to put the plumbing underground where it belongs. I admit that this is an asthetic judgement, but it makes sense to me. Your code might detect an unusual condition several levels down and want to know the value of something at the top level-- certainly you could percolate this data or create some sort of global variables etc, but in my asthetic sense it's much more appealing to go and grovel for the data in the rare cases when it's needed rather than forcing everybody to look at your dirty laundry all the time. Imho it's exactly analogous the exception handling, you *could* achieve the same effect by passing all kinds of return flags around, but popping the stack is so much more comprehensible. Back to the question, as Marc asks, how does the debugger do it? the debugger has no problem displaying all the local variables etc. I *assume* the values or pointers are simply coming from the stack. It's also clear that the debugger sometimes gets confused, so examining the stack isn't a slam dunk. What i don't know for a fact that external information gotten from compiling "Debug" isn't required. Also as Marc points out, what i really want isn't exactly the class instance but rather the contents of the field instance.Foobar-- i'm assuming that c# internally uses some sort of pointer and that if i'm either in the correct namespace or able to use reflection that given the instance pointer or whatever it should be easy to get the value of Foobar. Anyway why would StackFrame return all the cool type information if it wasn't useful? I have to believe Stackframe is intended for more than just getting the NAMES/ signatures of the methods on the stack. Again, thanks, and thanks in advance for any more hints. _______________________________________________ Go see Shrek2. Tell me if it isnt the best movie ever. Then read the credits at the end of the movie and estimate the animation budget.

[leppie]

run tlbimp on cordebug.tlb in the lib dir of the SDK root. That should give you enough to play with (unfortunately its still in my to look at list, so gimme a shout if it works well). top secret xacc-ide 0.0.1

[Heath Stewart]

TuringTest1 wrote: is that because interpreting the actual data on the call stack is language dependent, No, because all languages targeting the CLR compile to Intermediate Language, or IL. The source language you use to write an assembly has little to do with the compiled code (though some compilers support different features of the CLI and compiler optimizations can change the IL a small amount).

Microsoft MVP, Visual C# My Articles

[TuringTest1]

Thanks be to Leppie! (can't claim i understand it quite yet but google cordebug seems to be the place to look). Again, thanks! ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain!