I am using Visual Studio 2005 with Team Foundation Server.
When I right click a file under the source control and choose "compare" VS appears to freeze until I hit escape. My guess is that the window that is supposed to be popping up is somewhere I can't get to. I tried minimizing all the windows that I can and it is nowhere to be found.
Try the keyboard shortcut to get to the window's main menu () then hit 'M' for move and hit an arrow key to attach the window to the mouse - then at the next move of the mouse it should jump to it.
Experiment with a window you can see first.
i had the same problem when trying to check in to TFS - no dialog and ESC escape key undid the freeze.
I had recently, before the problem, changed my Laptop + Monitor configuration as follows:
from Primary screen being the laptop and secondary screen being the monitor
to primary screen being the monitor and secondary being laptop.
I got rid of my secondary screen and tried again. SUre enough the invisible dialog was no longer invisible.
I had to disable my Second Screen as well. Now the check-in screen where you can add a comment IS visible.
Related
Good day,
I'm currently experiencing a weird phenomena, this morning as I open the dbgview application an error message popped out(kernel related), couldn't remember much about the details.
Although the dbgview was showing at the task bar but as I clicked on it, it will jump out to no where.
It was as if I have 2nd monitor and it jump out to other screen.
I checked with 2nd monitor and it was not there..
I tried to install the latest version.
System recovery back to few days before which was still in working condition. But it doesn't help.
Hope someone here could show me some clue.
07/07/2020
I discovered it might not related to debugview this app. As I opened up task bar and select the debugview application and maximize the window size it is showing up. However as long as I click restore button at the right top corner of the app it flew out to the universe again....
Thank you
DbgView remembers its last position, so what likely happened is that you disconnected a monitor while DbgView was running on it, or maybe you accidentally dragged DbgView offscreen, and now it opens in a position that's no longer visible. Try either of the following.
With DbgView running, Alt-TAB to it then press Alt-Space, M (which opens the system menu and selects Move). While the "move" cursor is showing, use the arrow keys to bring the window back onto the active screen.
With DbgView closed, run regedit, navigate to HKCU\Software\Sysinternals\DbgView and delete (or rename) the Settings value, then run DbgView again. Since it no longer finds the old saved position in the registry, it will now open in the default position on the active monitor.
Try this:
start dbgview
hold the left 'Windows key'
while still holding the windo
I'm running VS2013 Professional on Windows 7 x64 and often finding that, after a debug session, the yellow tooltips from the debugger don't go away and stay on the screen on top of other windows. For example, the image attached shows a debug tooltip now also showing on top of me posting this question.
I am able to hide it temporarily by pressing Win + d to show the desktop, but as soon as I open / navigate to any window, the tooltip is right back.
The only way I've been able to get rid of these tooltips has been to close and re-open my Visual Studio. Any thoughts about what else I could do?
Try sending the WM_CLOSE message to the tooltip window.
I had hoped to be able to do that with Spy++, but alas you can't send messages from that.
I downloaded SendMessage from StephansTools, this then lets me use the cross hair to select the offending tooltip window and then send the WM_CLOSE message to it.
Caveat: This only seems to work in some circumstances. It's worth a try but may not work every time.
On your screenshot, the tooltip is "this is the next statement that will be executed". This tooltip appears when you hover over a yellow arrow to the left of the code while stepping in debugger (there must be no breakpoint on the current line).
It's quite likely that when the tooltip is stuck, you can un-stuck it by howering over that yellow arrow again, then moving mouse cursor away from it.
As for permanent solution to the problem, I would blame third-party applications that install hooks. Try to temporarily disable whatever such software you have and see if it helps. If you can't figure the exact repro to get the problem, you can simply close any other software you can and do your debugging for a while.
Some typical examples of hooking software:
Input assistance (voice to text, ...)
Automatic keyboard layout correction
Dictionary and language translation
Anything that creates new buttons in other programs
Screenshot software
this has been bugging me for quite a while now.
I'm using two monitors and usually have the main window of Visual Studio open on the primary monitor and things like the solution explorer, call stack, error list, output etc. on the second monitor in two separate windows which I split vertically by using the [Win] + [Left | Right] shortcut.
In another environment, this works fine (VS 2013, different machine). Of course, the window positions etc. are different between debug and regular view, but that's not really an issue.
Whenever I start debugging, the solution explorer window moves towards the right on the second monitor. This might even affect the other window (which contains the Call Stack, Output etc.).
After a few debug sessions, the window will be barely visible any more because it has moved so far towards the right...
This is even worse when I have multiple solutions open because then the solution explorer window that I see is actually the one from the instance in the background...
Has anyone else experienced this? Any ideas how to fix this?
P.S.: I'm working on a windows server via a RDP session, maybe that contributes to the problem.
The following worked for me.
Under the Windows menu, save the desired layout with "Save Window Layout". I named mine "Debug". This might have something to do with the old layout names.
Stop debug mode if your in it, and apply that layout with "Apply Window Layout".
Start debug mode.
My un-docked windows flash as if they are resizing, yet stay where I had them in the saved layout.
While debugging, for time to time, i use the F12 button to view function's definition / declaration. Usually, VS opens the needed file as a secondary tab in the main menu. Recently, not sure what i've done, it started opening the code in the lower menu, making the debugging process difficult to perform.
I think you've previously docked one or other window in an unintended position on screen. The visual up/down/left/right indicators shown when docking windows have different options for the down position and I suspect leads to this behaviour. Play around with the docking, or try the Reset Window Layout menu item under the Windows menu.
When I'm working in Visual Studio 2010, the IDE seems to switch to "Scroll Lock" mode at random times. Is this a new feature that I'm not aware of (initiated by some designated key/mouse-click) or a bug? I'm guessing this is actually a computer/hardware glitch on my system, but wanted to check if anyone else is experiencing this issue?
After I'm in this "mode", I can't seem to get out of it. I've tried physically turning ScrLk on/off multiple times, highlighting text, etc. I 'crazy-clicked' my way out of it once, but have no idea how. At that point, my only option is to close the IDE and restart, then everything is back to normal.
it thinks the control button is pressed, so just press control and it should fix
Nope, it's a CTRL key bug... using the left key all the time and occasionally, VS2010 will freak out and let the mouse wheel operate independently for zooming rather than scrolling, Shift-F5 won't stop debugging, etc.
Solution for me.... hit the right CTRL key. Dunno why, but it made it go away.
This is certainly not a feature of Visual Studio itself. It is possible, although I would agree unlikely, that a third party extension is causing this behavior. To rule this out I would disable all extensions and see if the problem still occurs.
If it still occurs then I would grab another keyboard to test the hardware issue.
There is a known bug in Visual Studio 2010 that does this sort of thing.
The way I have experienced it is that the left CTRL key will get "stuck" in the application (it doesn't seem to happen with the right CTRL key).
When this happens, you start to get bizarre behavior (like the scroll lock effect with when you hold the ctrl-up/down arrows, or being unable to stop debugging because it will restart the application when you do SHIFT-F5, or you change the size of the code text when you use the scroll wheel).
Unfortunately, there is no fix for it coming in for VS2010. You have the choice of living with it, or upgrading to VS2012. Others have re-mapped some of their short cuts to work around these problems.
for those who have this problem and reading this..
I found a way to bypass this problem and all you need to do is-
close the little window of Properties in the right-down corner.
and no longer you'll have this bug. :)
Do you really mean ScrollLock? AFAIK VisualStudio does not change in behavior in any way in response to ScrollLock.
I suspect what you are experiencing is VS incorrectly believes one or more of your modifier keys are held (ctrl, shift alt). To correct this press and release each of the modifier keys one at a time while VS has focus.
Real example:
The app I am debugging has focus and I am holding the ctrl key for an in-app function when I suddenly hit a breakpoint giving VS focus. However VS appears to have not registered that I have released the Ctrl key so my first attempt to scroll within the document using the mouse-wheel results in my font dpi changing... (ctrl+wheel = zoom)
Fix:
Press and release the the modifier key while VS has focus.
I had this issue where the scroll wheel on my mouse would change the zoom percentage of my open code. Pressing ALT while Visual Studio was in focus worked for me.
The solution for me was to hit the left CTRL key. Dunno why, but it made the problem go away. This answer is different than the one above suggesting to hit the right CTRL key. I tried that first but it did not fix the problem. But when I hit the left CTRL key it did fix the problem.
Another option is to exit Visual Studio 2010 and start it up again.
I had this issue ever since I moved to another development machine, I thought my graphics card was the issue, almost had the boss order me new ones, as I could not get this resolved. Turns out closing the property window immediately fixed the issue!. My previous fix was to float all and not keep anything opened in the pinned tab area, which works, but is inconvenient.