1

I've got the following structure:

public struct MyStruct
{
    public bool property1;
    public bool property2;
};

I would like to know how to break during debug when the value of property1 changes (without re-writing them as property with getter/setters, I can't do that)?

Any ideas?

halfer
  • 19,824
  • 17
  • 99
  • 186
Emmanuel Istace
  • 1,209
  • 2
  • 14
  • 32
  • 4
    These are fields, not properties. There is no setter/getter code on which to place the breakpoint – Panagiotis Kanavos Jun 15 '15 at 11:31
  • public fields are generally a bad idea in the first place. – Rik Jun 15 '15 at 11:33
  • @Rik Not always. Why do you think they are? – Thorsten Dittmar Jun 15 '15 at 11:34
  • 1
    Please guys don't mark this as duplicate with any answer that *doesn't* include conditional breakpoints. The OP is asking about *fields*, there are no setters. – Panagiotis Kanavos Jun 15 '15 at 11:36
  • @PanagiotisKanavos : Updated my question title, sorry :) – Emmanuel Istace Jun 15 '15 at 11:40
  • @Rik : Not my choice, have to deal with it... – Emmanuel Istace Jun 15 '15 at 11:40
  • You can't put breakpoints on a field - it's just a memory location. You'll have to find the places where the fields are referenced and put breakpoints there. Or encapsulate this logic in a separate method, one that would essentially act as a setter – Panagiotis Kanavos Jun 15 '15 at 11:41
  • @ThorstenDittmar That's why I said "generally". Public fields expose implementation, which you generally want to avoid. – Rik Jun 15 '15 at 11:55
  • @Rik So instead you'd use what? A property with an auto-getter/-setter? What's the point? If you don't add any logic by implementing at least a setter that does more than just set a member variable, why would you use a property? (being able to set breakpoints aside :-)) – Thorsten Dittmar Jun 15 '15 at 11:59
  • @PanagiotisKanavos *it's just a memory location* that alone isn't the reason you cannot put a breakpoint on it though, the c/c++ debugger for instance can halt at 'data breakpoints' i.e. it will break when memory at a certain location changes. Which is exactly what the OP wants. – stijn Jun 15 '15 at 12:01
  • @stijn forgot about it - in fact even VB6 had data breakpoints. We are talking about .NET though, which doesn't have them – Panagiotis Kanavos Jun 15 '15 at 12:42
  • @ThorstenDittmar The point is to hide the implementation. Unless you're an edge case, there's no reason not to. The point is of auto-properties is that it takes zero effort to define a property over a field, but changing a field to a property later is a breaking change. Maybe you don't need any logic in the getter or setter now, but you do need it in the future. Changing a field to a property then requires more changes (including recompiling of all code that uses it) than changing an auto-property to a custom one. – Rik Jun 15 '15 at 12:59

2 Answers2

3

These are fields, not properties. They are modified directly by other code so the only place where you could put a breakpoint is the code that modifies them.

What you can do, is create a conditional breakpoint that will break when a condition becomes true or a value changes. This is described in How to: Specify a Breakpoint Condition. Essentially, you right-click on a breakpoint and then click Condition from the shortcut menu.

This way you can put conditional breakpoints to any place that may modify the field. Again, you can't place the breakpoint on the field itself - it's just a memory location.

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
  • Thank you, but I wanted to put a break point on that field because it's in fact an object graph, some parts of the graph are replaced, multiple instances exists, graph is sent to native code and modified there, and that graph is core for the application so used and modified everywhere and I can't find who's responsible for the specific modification I try to debug... So your solution is in fact the reason of my question in a way :p Thanks anyway ! – Emmanuel Istace Jun 15 '15 at 11:48
0

If there are not too many places which are writing to the field, I would set breakpoints there.

Stefan Steinegger
  • 63,782
  • 15
  • 129
  • 193