Visual Studio: How to stop breakpoint hit from stealing focus?

Question

When a breakpoint is hit in Visual Studio, it steals the focus from whatever other application the programmer is viewing/typing into at that moment. This can be very irritating since VS grabs any keyboard input the programmer was typing into the other application at that moment and takes that input as its own.

What are the tricks you folks use to prevent this focus steal?

(I face this on Visual C++ 2008 and 2010. I am guessing it is a problem for Visual Studio in general and for all recent versions.)

This is not a Visual Studio issue. This is a feature of the Windows operating system. — AMissico, Jul 13 '10 at 08:45
I'm still waiting on a usable solution to this. I turn breakpoints on and off continuously during the day. None of the answers so far helps. — Daniel Williams, Jun 20 '18 at 20:56

score 31 · Answer 1 · answered May 23 '19 at 18:58

31

This is finally fixed in VS2019. Go to Tools->Options->Debugging->General, down at the bottom is "Bring Visual Studio to the foreground when breaking in the debugger."
Just de-select it and you will no longer be interrupted while multitasking.

answered May 23 '19 at 18:58

Daniel Williams

8,912
15
68
107

This works amazing, but now I'm annoyed that the task bar item no longer lights up when a breakpoint is hit... – Corstian Boerman Oct 23 '19 at 06:57
2

Yeah, I will forget I'm debugging sometimes and then have to open VS to see I'm on a breakpoint. But it's so much better than getting randomly interrupted while typing! – Daniel Williams Oct 24 '19 at 16:04
I decided to create a feature request for Visual Studio regarding highlighting the task bar: https://developercommunity.visualstudio.com/idea/790650/highlight-the-task-bar-item-when-a-breakpoint-is-h.html – Corstian Boerman Oct 25 '19 at 08:18
Does anyone know if we can get it to stop flashing the taskbar as well? It's making me anxious! – Daniel Williams Apr 27 '20 at 16:21
File > Preferences > Settings. Type in search: "Debug: Focus Window On Break" – Brent Sandstrom Sep 21 '21 at 16:04

AMissico · Answer 2 · 2010-07-13T18:07:09.187

17

This is a registry setting. See ForegroundLockTimeout at http://technet.microsoft.com/en-us/library/cc957208.aspx. Zero allows applications to steal focus. TweakUI sets this value to 200000 when "Prevent applications from stealing focus" is checked.

For more control, download the Tweak UI utility of Powertoys for Windows XP. In the "General" tab, select "Focus" and check "Prevent applications from stealing focus".

Google search for ForegroundLockTimeout at http://www.google.com/search?q=ForegroundLockTimeout
Bing search for Prevent applications from stealing focus at http://www.bing.com/search?q=Prevent+applications+from+stealing+focus
Applications Stealing Focus on Windows XP at http://mycvs.org/archives/2004/11/16/applications-stealing-focus-on-windows-xp for screen capture of TweakUI.
Please Don't Steal My Focus, Coding Horror, Jeff Atwood at http://www.codinghorror.com/blog/2007/12/please-dont-steal-my-focus.html

The strange thing is, there are provisions built into the operating system to protect us from badly written, focus stealing applications. The ForegroundLockTimeout registry setting is expressly designed to prevent applications from stealing focus from the user. The OS silently converts that inappropriate focus stealing behavior into friendlier, less invasive taskbar button flashing, which is the subject of the ForegroundFlashCount registry setting.
How To Prevent Programs from Stealing Focus in Windows XP at http://www.howtodothings.com/computers-internet/how-to-prevent-programs-from-stealing-focus-in-windows-xp

edited Jul 13 '10 at 18:07

answered Jul 13 '10 at 08:39

AMissico

21,470
7
78
106

8

The value of ForegroundLockTimeout in my registry on Windows 7 is 0x30d40 (200000) already and yet I see VStudio stealing focus when a breakpoint is hit. – Ashwin Nanjappa Jul 14 '10 at 01:51
5

I confirm this answer addresses the focus-stealing behaviour of virtually every application but Visual Studio. – sam hocevar Nov 29 '10 at 14:22
3

Unfortunately Visual Studio appears to not care about this setting. – Ryan Ternier Jul 26 '12 at 19:40
@RyanTernier; Which OS? I notice that Windows 7 has its own idea about application focus. – AMissico Jul 26 '12 at 22:44
@AMissico Windows 7. Yea, it plays by it's own rules. – Ryan Ternier Jul 26 '12 at 23:10
7

Microsoft's hobby is bypassing their own features. They think they own the place. It's bloody annoying. – jcarpenter2 May 14 '14 at 14:46
I can confirm that this issue still occurs with this registry setting on Visual Studio 2013 running on Windows Server 2012 R2. – Albert Armea Jul 14 '15 at 21:40
See my answer above https://stackoverflow.com/a/46785877/514793 for a Windows 7+ solution. It's crude but it does the job. – Jools Oct 17 '17 at 08:50
1

It takes advantage of the fact that Microsoft "think they own the place" ;-) – Jools Oct 17 '17 at 08:52
A windows update allowed this setting to start working. This prevented focus from being transferred when expected. e.g. I was unable to click icons on the taskbar and have them show on top. – Hans Vonn Jul 10 '19 at 16:56

score 9 · Answer 3 · answered Jul 13 '10 at 08:32

9

Right click the breakpoint and select When hit ... this will allow you to run a function when the breakpoint is hit. You can use this to print status messages to the output window. You application will keep focus.

answered Jul 13 '10 at 08:32

Brian Rasmussen

114,645
34
221
317

1

This is very useful -- I use this technique a lot (though it can really slow down the app) – the_mandrill Jul 13 '10 at 12:36
1

Yea, this is pretty useful! I was testing some WinForms behavior involving `Focus` and VS was messing me up pretty bad. This method solved my problem (since the fix/hack marked as answer doesn't Win 7). – Jeff B Feb 04 '13 at 22:25

Jools · Answer 4 · 2017-10-17T08:44:21.810

By accident I discovered a workaround, which I've been using for a few years now and while I haven't tested it in 2008 and 2010, it certainly works in 2013, '15 & '17 and at least Windows 7 & 10.

It relies on the fact that Visual Studio will not steal focus if another Visual Studio instance is paused in execution. Obviously the only thing as special as VS is another VS. :-/

Open a second instance of VS with a simple project. Pause the execution of the project anyway you like (e.g. put a breakpoint on the first line of execution and debug), you can then simply minimise that VS and none of the VS instances you're actually using will steal focus.

This is is obviously a heavy weight solution, but if you have ample RAM (the CPU usage of the idle VS doesn't even register for me), it works well. I haven't tried it with inter-version instances (e.g. pausing in '13 to make '17 behave), but if that works you'll probably want to opt to use the older version instance as your "dummy" VS to cut down on resource use.

This is the only suggested solution that works, yet it too heavy for me to use. — Daniel Williams, Apr 04 '19 at 17:49

score 0 · Answer 5 · answered Jul 13 '10 at 08:30

One workaround is to use OutputDebugString() function to output current state into the debugger output window. You just place Visual Studio in background, position the debugged program window so that the "Output" window is visible - and no focus transition ever happens.

You will perhaps want to use macros for conditional compilation so that tracing code is not included into the release builds.

Visual Studio: How to stop breakpoint hit from stealing focus?

5 Answers5

Linked

Related