views:

57

answers:

2

The following has been edited. Hans seems to have retracted his answer, but his questioning has helped me to narrow down the problem statement:

Extra Clarity

  • I do not want to modify the behavior of Ctrl+C.
  • I'm not looking for a work around.
  • I simply want the debugger to NOT break when Ctrl+C is pressed during a debugging session.

Please note that the following example is contrived. It's just to demonstrate the behavior. I changed the ReadKey line as it was distracting people.

Debug (run) the following program:

class Program
{
    static void Main()
    {
        System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite);
    }
}

Press Ctrl+C. The debugger will break as if you set a breakpoint on the Sleep line.

How do you turn this off? I don't want the debugger to break at all for Ctrl+C.

This doesn't happen at home with VS2008 Pro.

I have now tried it with both VS2008 Express and VS2010 Express (the only editions I can test it with easily) and they all do it. This has led me to believe that either it's an Express behavior, or that there is a setting somewhere to toggle it on/off.

  1. Is there a setting to turn this on/off in any version/edition?
  2. Does this setting exist in VS2008, VS2010, or both?
  3. Is the setting exposed in the Express editions?
  4. Is my instance of VS2008 Pro unique? Is the setting something that was exposed in an old version of Visual Studio that has carried over (I have carried over VS settings through many new versions).
A: 

CTRL-C is wired directly to the console window itself for the 'break' operation. Open a new console app, ping something, then immediately press CTRL-C. It aborts the ping.

You said VS Pro didn't have this behavior. I'm assuming it was just itself setting SetConsoleMode whereas VS Express doesn't. However, you can still tell the console directly to ignore CTRL-C and treat it as straight input yourself with SetConsoleMode. See this link for details:

Here's how you declare the function for use in both C# and VB:

Just put the call with your chosen mode options at the beginning of your program and you should be good to go!

Hope this helps!

M

MarqueIV
@MarqueIV: See **Extra Clarity** in my edited post.
Tergiver
@MarqueIV: Thank you for wanting to help. In light of the most recent edits (removal of ReadKey in particular), how would you reconsider your answer?
Tergiver
Not sure I'd change my answer. If the console is wired to read in CTRL-C as a break, and VS received a break, then goes into debug, telling the console not to break and instead treat CTRL-C as input would solve your problem. Again, I'm pretty sure VS Pro is doing what I'm suggesting automatically because again, CTRL-C is a behavior of the console that VS Pro is probably overriding. In VS Express it seems you have to. If you're worried about code being added, put in a compiler directive to be excluded when building in Pro.
MarqueIV
Also, your points 1 and 3 are contradictory. You are asking to change the behavior. Again, I'm pretty sure VS Pro just does what I'm suggesting to automatically. Same reason running a console app in either debug or release changes what happens when its finished (one closes, the other pauses and waits for a key press when done.)
MarqueIV
One last thing... you could always write a separate program that sets up the console, then launches your console app itself (perhaps via a command-line argument.) That way all the code to set up the console is in a completely separate project. Just some food for thought.
MarqueIV
A: 

I found the answer, it is a debugging Exception option. I don't know how I missed it the first time, but here it is:

Debug -> Exceptions... Win32 Exceptions - Control-C

This is in VS2008 Pro.

I can also confirm that the option does NOT exist in the Express editions (the entire Win32 Exceptions node is missing).

So the only question I have left, since I don't own VS2010 Pro (yet?) is: Does the Win32 Exceptions node, and the Control-C exception exist in the VS2010 Pro edition?

Tergiver