-1

I have a form

enter image description here

I have the variable 'a' declared at the class level.

  public partial class Form1 : Form
    {
        int a;
        public Form1()
        {
            InitializeComponent();
        }
        ..........
    }

I have button click events, one button increments 'a', the other decrements 'a'

I want to view 'a' in the watch window, this should idealy be possible as soon as a form loads as the program doesn't just terminate there, but anyhow, it seems I have to put a breakpoint somewhere in order to view 'a', so I put a breakpoint at the form load and hit 'play' and see 'a'.

I click 'continue' and i'd like to see the value of 'a' when I click the buttons.

But it seems to only do it on a breakpoint. Once I hit a button, then unless I added a breakpoint, it won't show me the value.

enter image description here

enter image description here

I don't really want to have to set breakpoints just to see the value of a variable wherever it is in the program. And I also don't want to have to jump into my code when i'm really trying to just navigate the GUI and see the value of variables as I do so.

The best I can do at the moment, it seems, is put breakpoints at a curly brace of the first form load and the ending curly brace of the relevant events that could affect the value. But it seems like it shouldn't be necessary to do that and it is a slight distraction if trying to click around a gui, to have it keep jumping into code. In a more complex GUI I might want to click around a bit to see if I can create an inconsistent state with respect to my variables, being paused like that on every click seems unnecessary and a slight distraction.

I'd like to monitor the variable throughout the program, rather than just at specific points. I am a little surprised if there isn't an option to do so, or perhaps there is but I can't see it.

barlop
  • 12,887
  • 8
  • 80
  • 109
  • I'm not aware of anything other than manually calling `System.Diagnostics.Debug.WriteLine`. – Reza Aghaei Jul 14 '16 at 04:19
  • It's not clear what you're asking. The debugger watch window by design only shows data when the process is paused. Others have suggested you can write the value to the debug output. But is that really what you want? It seems to me that if you want to be able to interact with the program and constantly monitor variable values, you should build that into your program; either display the values in the main window somewhere, or create a separate "debug console" window where your program itself will display the values. Either way, you can make these features optional and/or in the debug build only. – Peter Duniho Jul 14 '16 at 04:21
  • @PeterDuniho having my own program show it seems a bit like messageboxes, or a slight step up , of a textbox. And a button to put the value in the textbox or show the value. I figured visual studio might be a bit more advanced and have that kind of feature in its debugging facilities, the watch window is almost there just not quite. And in the case of a list, the watch window shows it so well, just not anywhere. I'd need quite a few controls for debugging easily show the lst count and any element. – barlop Jul 14 '16 at 04:26
  • And how is Visual Studio's debugger not "a bit like messageboxes"? It's a separate window showing you the value. Anyway, like I said: it's by design that in the debugger you can only watch values when the program is paused. It's not practical to do it any other way. Debug-only features in programs is a common and broadly accepted means for doing what you're asking to do. – Peter Duniho Jul 14 '16 at 04:29
  • @PeterDuniho how do you make a textbox on a form that only appears in the debug version of the program? – barlop Jul 14 '16 at 06:36
  • You can conditionally compile code with the `#if`/`endif` directives. `#if DEBUG`/`#endif` around code will cause that code to exist only in the debug build of your program. You can, for example, programmatically add a label/textbox to your form in the constructor, only in the debug build. I will also suggest you use properties for displayable values, or at least only ever set a field via a method for the purpose, so you can avoid having to include code to update the displayed value every place you need to change the value. With a property/method, you can just put that code there. – Peter Duniho Jul 14 '16 at 06:47
  • slightly related- no great answer on this question, but emulating a watch window http://stackoverflow.com/questions/2231703/is-there-a-way-to-use-visual-studios-watch-window-in-my-own-app – barlop Jul 15 '16 at 12:00

1 Answers1

0

I think you'll have to write it to the output window:

a++;
System.Diagnostics.Debug.WriteLine(a);

It's not optimum but it's better than breakpoints.

Steve Wellens
  • 20,506
  • 2
  • 28
  • 69
  • Though you'd have to know where the variable is changing, / all the places where it might be changing, I suppose perhaps one should know, but is a bit laborious – barlop Jul 14 '16 at 04:22
  • @barlop: See my other comment above. For this scenario, you should make sure that whatever value you're trying to display, there is a single method (standalone or property setter) that is _always_ called when that value changes. That way, your debugging output is isolated to that one place, rather than requiring changes throughout the code. – Peter Duniho Jul 14 '16 at 06:49
  • @PeterDuniho well of course but you still have to call the method every place it changes, that's what I was saying in that comment of mine above yours that I think you were replying to – barlop Jul 14 '16 at 08:17
  • @barlop: if you make it a property, then you don't even have to change the code where it's used. The syntax is exactly the same. But even keeping it a field with a dedicated setter method would be a one-time change, with high value benefit. If none of that is palatable to you, you could just poll the value using a timer for updates. – Peter Duniho Jul 14 '16 at 08:31
  • @PeterDuniho Without a timer or dedicated setter, you are changing the code where it's used, you are copy/pasting a call.. The timer or dedicated setter is really good though, no copy/paste of a call. What about the fact though that a watch window lets you evaluate any variable, or expression.With a watch window I can do lst.Count() or lst[4] and see the value. I suppose with this method I'd need to add a combobox to display the whole list, and a label to display the count, and a textbox to enter the index of an element to view, and a button to get it to display. and a label to show it. – barlop Jul 14 '16 at 11:19
  • _"you are changing the code where it's used"_ -- no, you are not. If your field is name "foo" and you name the property "foo", none of the call sites change. The C# compiler does all the work for you. _"What about the fact though that a watch window lets you evaluate any variable, or expression"_ -- what about it? It will be more work to emulate that, yes...but you have no choice. The debugger simply isn't designed to do what you want. – Peter Duniho Jul 14 '16 at 14:33
  • I agree with @PeterDuniho. If you make the variable a property, then you can put the extra line of code in the setter....in just one place. – Steve Wellens Jul 14 '16 at 14:42
  • @PeterDuniho the first part of your last comment misunderstood me. Bear in mind that AFAIK, a property is a getter and setter for a field. So I agree with you that using a property with the same name as the field is a great solution for getting around that limitation of the watch window, but you don't have as great a solution for the emulation of the watch window as far as showing the value of a list. I could make a user control with a combobox textboxes and a button to show values for any index of a list. – barlop Jul 15 '16 at 11:58
  • @barlop: _"a property is a getter and setter for a field"_ -- no, not really. A property is a getter and a setter, period. Those methods can do whatever you want. They often use a simple field to store data, but that's not required. _"you don't have as great a solution for the emulation of the watch window as far as showing the value of a list"_ -- lists are more complicated, yes...but they can still be managed. `BindingList` and `ObservableCollection` both provide collection-changed notifications you can use for the same purpose. – Peter Duniho Jul 15 '16 at 15:29
  • @barlop: in any case, your complaint that "it's too hard" or "it's too complicated" or whatever just doesn't matter. These are the things you _have_ to do if you want immediate, real-time updates of changes to program state. – Peter Duniho Jul 15 '16 at 15:29
  • @PeterDuniho please don't put quotation marks around words that I never said/wrote, and i'm not dismissing what you are saying the way you might think that I am – barlop Jul 15 '16 at 19:24
  • @PeterDuniho You are welcome to post your answer and i'll accept it. Many of my comments in response to you were to bring forth the good arguments to justify your approach, and you have made some good arguments along with your suggested approaches. – barlop Jul 15 '16 at 19:50
  • @barlop: I don't see a good way to answer the question that was asked, even if you feel you got useful feedback. If you think that feedback produced information that would be useful for future readers, I'd recommend that you post a new question that is less focused on the debugger watch window and is more directed on the general goal of monitoring state at runtime, and then post your own answer to that question in which you describe the various feedback here that you found useful. – Peter Duniho Jul 16 '16 at 00:49