views:

89

answers:

2

Is there a way to have breakpoints hit when the action is caused by the Visual Studio debugger? For example, let's say I have the following (I know you shouldn't do this, just using it for argument's sake):

public class Test
{
    int _X = -1;
    public int X { 
        get { return ++_X; } //Breakpoint here
        set { _X = value; } 
    }
}

And:

static void Main(string[] args)
{

        Test t = new Test();
        t.X = 1;  //Breakpoint here
        return;
}

If you pause at the breakpoint in Main, every time you "hover" the mouse pointer over "t.X" (assuming you have the following Debugging option enabled - "Enable property evaluation and other implicit function calls") or you evaluate the property in the "watch" window - it will increment the property but the breakpoint in the property's "get" accessor will not be hit. Re-asking the question in a more specific context - is there a way to hit the breakpoint in the property's "get" accessor when the evaluation is done by the debugger?

A: 

Uncheck this option

Debugging -> General -> Step over Properties and Operations

have a look at this Post as well

Asad Butt
@Asad - I don't see that option; I do see "Step over properties and operators (Managed only)" but am I correct in understanding that enabling this will just step over the properties which isn't the desired result? I am not "stepping" when the debugger evaluates the property and changes it's value. Forgive me if I misunderstood what you were trying to say.
thedugas
Oh man, sorry, you need to "UnCheck" this option. Debugger will then Step Into Properties. Have modified answered.
Asad Butt
@Asad - I had that option unchecked when I posted the question. I do not want to step, I want to catch a breakpoint in the property's get accessor. Thanks for the input though.
thedugas
@Asad - I rolled back your edit of the title. I am not asking how to step into properties when debugging.
thedugas
+2  A: 

After some research on this topic, I learned about FuncEval, and after reading lots of things about FuncEval I was led to the following article: Stop Mid Func Eval, Nested Break States by Mr. SteveJS. In the article he explained that starting in VS2005 you could hit a breakpoint caused by a FuncEval if the evaluation was done from the "Immidiate Window" instead of the Watch or "Quick Watch" windows. So, in the above example, entering

?t.X

in the Immediate Window caused the breakpoint on the get accessor to be hit.

thedugas
+1. a very good piece of information
Asad Butt