Option to detect if method/property were called from within IDE's "watch window"

  • Thread starter Thread starter ambidexterous
  • Start date Start date
A

ambidexterous

Consider i have a following property



public List<Cover> GreenCardsToBeTerminated

{

get

{

return greenCardsForTermination ??
(greenCardsForTermination =

DetermineGreenCardsToBeTerminated()

);

}

}



Now is there some way to know that this code was called from the "watch"
window if IDE ?
Similar to System.Diagnostics.Debugger.IsAttached or DesignMode ?

At the time i am debugging i would like to look what is returned by the
property, before that property is accessed by the real thread (callstack),
but i don't want to interfere with the execution path. In this case my
property does some inicialization and i don't want that to happen before the
time... so i would like to do something like if (IsCalledFromWatch) execute
this code and give me the results and then turn back things to the original
state

Do i have any options here?
 
ambidexterous said:
Consider i have a following property



public List<Cover> GreenCardsToBeTerminated

{

get

{

return greenCardsForTermination ??
(greenCardsForTermination =

DetermineGreenCardsToBeTerminated()

);

}

}



Now is there some way to know that this code was called from the "watch"
window if IDE ?
Similar to System.Diagnostics.Debugger.IsAttached or DesignMode ?
Click to expand...

As far as I know, no.
At the time i am debugging i would like to look what is returned by the
property, before that property is accessed by the real thread (callstack),
but i don't want to interfere with the execution path. In this case my
property does some inicialization and i don't want that to happen before the
time... so i would like to do something like if (IsCalledFromWatch) execute
this code and give me the results and then turn back things to the original
state

Do i have any options here?
Click to expand...

Sure. Just probably not the ones you want:

* You can turn off property evaluation in the debugger altogether,
in the VS Debug settings.

* Or you can just not add the property to the watch window or
otherwise ask the debugger to evaluate it until you're ready for it to.

* Or you can watch the variable, rather than the property.

But I don't think there's an easy way to, in code, conditionally
determine that the debugger is what is evaluating the property.

Now, that said...note that the call stack will not have your own code in
it if the property is evaluated via the debugger rather than by the
execution of your code. I haven't looked at the specific differences,
but that's probably a way you could identify the difference.

The problem is that using the current stack state is slow. In this
case, it might actually be okay, because you'd only check for and change
the flow of execution in the initialization case. So in the execution
of your application, you'd only have access of the property be slow
once. But in the debugger, it would be slow every time you evaluate the
property while the value is still null. If the property is being shown
in the watch window, this could be a large number of times.

Personally, I'd just put the variable "greenCardsForTermination" in the
watch window instead. From your question, it sounds like _that_ is
actually what you want to watch anyway.

Pete
 
Back
Top