3

I apologize if this is a duplicate post, but I couldn't find the answer in any other thread.

I am aware I could step into my application by starting the debugger with F10 or F11. I am also aware that I could set a breakpoint on certain GUI events. However - this is not what I want.

I would like to be able to press a button somewhere in VS, and have it kick into "step-into" mode so that the next piece of user code that gets triggered is stepped through. I want to do this so I don't have to set breakpoints all over in my code. It would save me a lot of time to be able to get the application in a certain state, manually turn on step-into mode, and then do something to trigger code to run that I want to step through.

Any ideas?

Edit:

Here's a step by step since I didn't explain it very well. There are two suggestions to use the Break All, but this still occurs before what I'm trying to do.

My goal:

  1. Launch Application
  2. Manipulate Application without breakpoints/step-through
  3. Manually Turn on Step-Through
  4. Trigger code (click a button, hover over something, change focus, etc.)
  5. Be in step through mode at the code that was triggered by my action.

As you can see - the Break All command occurs as does not allow me to trigger step 4. It immediately halts the program, and I'm still left finding the code that will trigger when I perform an action.

I understand this may not be possible; I just want to hear that from the experts so I can stop looking for it.

hawbsl
  • 15,313
  • 25
  • 73
  • 114
Origin
  • 1,943
  • 13
  • 33
  • If I could have marked all three responses as the answer I would have. All three of you presented very similar (and helpful) information. But since @Jeremy provided more detail about how to use F10 and F11 for this issue I decided to give it to him. – Origin Jan 22 '12 at 04:54

3 Answers3

6

Yes you can break into the debugger, but it happens immediately.

You can press the "Break All" button (||) or Ctrl + Alt + Break.

It might not land you where you expect though. You could be anywhere in the application and probably not in your code.

It's far simpler to set one or two strategic break points, especially as you know which code you are going to enter.

Alternatively, disable your break points rather than remove them, run your program and then your step 3 becomes enable break points.

ChrisF
  • 134,786
  • 31
  • 255
  • 325
  • In most cases I would agree it is easier to set break-points, but for the scenario the opposite has proved true. The Break All button isn't exactly what I was looking for. I'll show a step-by-step in my question. – Origin Jan 19 '12 at 22:49
  • @Origin - I think you need to *disable* breakpoints. See update. – ChrisF Jan 19 '12 at 22:55
  • +1 for keeping a number of disabled breakpoints. Also conditional breakpoints are another tool....but they can really slooow the execution. – kenny Jan 19 '12 at 22:58
  • Thanks for the update. I considered this - but unfortunately it still doesn't help a whole lot. If there were "groups" of breakpoints that I could turn on/off (one set for UI debugging, one set for something else, etc.) then this would be a great option for me. But alas, if I go through and set up all my breakpoints on my UI, and want to test some specific piece of code (and none of my UI) I can't have it magically turn off the UI breakpoints and leave my current focus unchanged. That's why I was hoping for a more "live" approach. – Origin Jan 19 '12 at 22:58
2

I don't believe this is possible as you imagine it. There is a "pause" button in Visual Studio which will immediately break into the debugger. However it will stop immediately even if the current instruction is not a part of your code.

After the break though a couple of quick F10 or F11's will get you back to your code.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
1

Occassionally I use "Disable Break Points" and "Enable Break Points" to do what you want, otherwise I do what ChrisF answered.

Also another trick with ChrisF's answer, when you Press Ctrl + Alt + Break and you F10 or F11 till the code finishes and your left seeing application, the IDE is still in step thru mode - meaning when you say click a button the event wont just fire off, the IDE will halt in the first line of code in the button click event, even though the button click event doesn't have a breakpoint in it.

Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
  • Thank you for your response. Unfortunately - the "til the code finishes" is the issue. I'm working with a form with multiple bound form objects that have cell formatting calls. It is **very** annoying to try to step through these types of functions, and because they can be called sporadically based on if I hover over a cell it would be easier to initiate the step-through mode only when I'm ready. Some of these formatting functions I'm debugging, others I'm not. I tried using attributes to have this code ignored by the debugger, but this requires a rebuild each time I want to turn it on/off. – Origin Jan 19 '12 at 23:07
  • I see, possibly Conditional BreakPoints could be the solution, perhaps you could declare several global variables that allow you to break on some formattinng functions. – Jeremy Thompson Jan 19 '12 at 23:18
  • 1
    Thanks, I didn't think to use some variables to better define conditional breakpoints. Unfortunately, half of my development time is spent in VS Express. I Did find a reference to the pre-processor directives which may be even more effective at this "grouping" I'm looking for when combined with causing a break in code. http://stackoverflow.com/questions/1030535/how-do-i-create-a-breakpoint-using-conditions-c-express – Origin Jan 19 '12 at 23:33