IE8 has a feature that pops up a dialog box that informs me when a web page stops responding that's a bit annoying when debugging as it steals focus from visual studio. Is there a way to disable that feature?
This was just covered on the IEBlog here.
From the blog:
While we continue to track the
telemetry, if you are debugging IE
either with the IE Developer Tools or
a debugger, and you attempt to
interact with the IE window, there is
a chance that you will see this
dialog. Although this will not impact
your debugging it may be more
convenient to turn this dialog off. Or
if you’re running Win7 RC and are
seeing this prompt more than you
should or would want to, you can turn
it off by changing the following
registry key:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main!HangResistance, DWORD, 0
Related
If I close a browser running a web application, it is desirable that the debugging session dies. After all, this equals to closing a windows application. However, if I stop debugging and the browser has more than one tabs (as often is the case), all of them will close - definitely not what I intended. Not using this option means I continuously forget the debugger running and clicking the stop button is just extra work.
Is there an add-on to Visual Studio or any other trick that allows to do only the first: stop debugger when window is closed?
Who thought it would be a good idea to put two options behind a single checkbox? This is a double-edged sword at its sharpest!
It's not exactly what you want. But, it might be a workaround. If you enable JavaScript debugging in Tools->Options->Debugging and then you Debug->Detach All. The browser should stay open and debugging should stop... Now it would mean that the application is still running, which might not be desirable.
It's a great suggestion to make this an option. I'd encourage you to open a suggestion on developer community.
Tools Options:
Detach:
I'm trying to improve my site's performance in IE11 and I cannot seem to get any results out of the performance profiler. I've read this page and it seems pretty straightforward but I must be missing something. Here are the steps I take:
On the F12 tools Performance tab, I click on either the green play button or the "Start profiling to begin a performance session (Ctrl+E)" link.
I perform an action in my app (as simple as clicking on a field and back out)
I hit the red stop button or the Stop profiling to generate a report (Ctrl+E) link
The Profiler tab shows "Analysing the collected data:" with an empty progress bar. The progress bar never goes anywhere and after a few seconds the Profiler tab just reverts to saying "Start profiling to begin a performance session (Ctrl+E)".
This happens on any website that I try, not just mine. The rest of the F12 tabs (DOM, Console, Network) all work fine. Using IE version 11.125.16299.0, update version 11.0.49 on Windows 10.0.16299.
What am I doing wrong?
I don't think you're doing anything wrong. The performance profiler appears to be unable to show the reports it generates in IE11 right now. However, the fact that IE and Edge seem to share their debugging tools (in Windows 10 at least) might offer a viable workaround.
Press CTRL-E, perform your actions, press CTRL-E again, and wait for the performance tab to revert to its initial state. Some part of the profiler seems to have crashed at this point; you'll find that the "import" and "export" buttons won't work.
Exit the debugging tools, open them again, and open the performance tab.
Click on the (now operational) "export" button to save your profiler report.
Open Edge, start its debugging tools, and go to the performance tab.
Import your saved profiler report. It'll show up just fine now.
For what it's worth, importing your saved report into the IE11 debugging tools will result in an error about "Promise" being undefined or somesuch. This makes sense, as the ES6 Promise constructor is supported by Edge but not by IE11.
When adding a new view via the "Add View..." dialog in VS2010SP1 with IIS Express running my site, the dialog hangs when pressing the Add button. Usually takes a couple of minutes for this dialog to finish ( whereas without IIS Express running, it finishes immediately ).
When closing IIS Express during this hang, the dialog finishes immediately.
Does anyone know what causes this, or how to fix this? Known issue? I don't want to close and restart my IIS Express everytime I add a new View.
There is a solutions listed here. This only happens to me when I have vs running for a long period of time so I haven't tested it yet.
http://social.msdn.microsoft.com/Forums/eu/csharpide/thread/d8c6c742-0241-40ab-8cac-dd58fb9a7c61
Turn off "Use Hardware Graphics Acceleration if available"
It's under the generals tab in options: Unclick "Automatically adjust visual experience based on client performance" and then unclick the "Use Hardware Graphics Acceleration if available".
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 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.
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
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.
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.
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.
By default, in Visual Studio and in SQL Server Management Studio, Ctrl+Tab opens a navigation popup which lists all the open windows. The idea is that you can press Tab multiple times while keeping Ctrl pressed; as soon as you release Ctrl, the navigation popup disappears and the selected document is activated.
Unfortunately, as soon as you ever run Microsoft Narrator (text-to-speech reader), this behaviour changes. The popup no longer disappears when you release Ctrl; it waits until you press Enter to select a document. While I can appreciate this behaviour may be reasonable for blind people who are actually reliant on Narrator, I find it rather irritating that the behaviour has changed permanently and that the old behaviour doesn't return even if I stop using Narrator completely.
Is there any way to restore the old behaviour so that it doesn't wait for an extra Enter keypress anymore?
Be patient and it magically starts reverting to normal after not using Narrator or Speech Recognition for a month or so.
I know this is old, but still an issue with SQL Server Management Studio (SSMS) 2008 when Speech recognition is running on Windows 7 (32bit Ultimate).
Worse yet, there is no fix per se. As a workaraound, I exit Speech Recognition, and then ctrl-tab behaves as expected.
I saw a post for changing Narrator settings, but none of the settings in Narrator (text to speech) have any effect on the issue.