>>Nic Ferrier original request
>Paul's reply
>>2. to see the state of a method in any particular thread
>>using the browsable list of threads method it's easy - you just
show
>>provide the entire stack frame under each thread
>This is a bit fuzzy to me. Let's see if I understand you. Let's
suppose
>that your app has two threads of interest, A and B, and that you
are
>stopped at a breakpoint in thread B in method Foo. What you are
saying,
>is you would like to be able to get the following info:
>
>1). A list of all the local variables defined for method Foo (i.e.,
on
> its stack) and the values for those variables that are in
scope.
>
>2) Thread A is currently suspended (since B is executing). So you'd
like
> to know what method thread A is suspended in and further all the
local
> variables for that method (i.e, its stack).
That is exactly it.
>>3. to concentrate on one thread
>>Sometimes I don't want to jump across code because another thread
>>comes in, I just want to debug in one thread.
>Let's see if I understand this. You're app has threads A and B and
>you're stepping through code on thread A, when you execute some
>code that causes thread A to be suspended and thread B to resume
>at some other point in the program. You don't want your next step
>command to take you to that point. Instead, when you issue the step
>command, you want the debugger to be smart enough to wait until
>thread A resumes and then move to the next step in thread A. Right?
Again, exactly right.
Thanks again for this, it's a hell of a tool!
