I love to open many tabs (10-30) of .cpp and .h, so the tab are overflowed to the right, i.e. Visual Studio can't show named of all opened tabs at the same time. (which is ok)
When I pin a new tab or change Visual Studio resolution (resize its window), Visual Studio will try to determine which one should be shown and which one should not (that is what I think).
In rare cases (1%), Visual Studio fail to do so. After I pin a new code tab (e.g. .cpp), it loops forever. For example, in the image, it is possible that the last of the four tabs will appear -> hide -> appear -> ... so on (forever).
Visual Studio would try to update other GUI to match the appearance/disappearance of the tab (e.g. width of console pane ?).
Within about 1-3 seconds, if I don't resize the window, Visual Studio will become unresponsive.
I will have to terminate it, lose some of my work.
It is like a mini-game.
I am sure that is a bug of Visual Studio. Have anyone faced it?
(Please comment if you faced the same problem!)
I don't think it is related to plugin "Visual Assist" or "Resharper".
I always set my monitor to low-resolution (1280 x 720), but I don't think it is a problem.
Question: How to solve this swappy bug, or at least avoid/alleviate it?
Related
I am coding a C++ project using MFC in Visual Studio (v16.5.4). The dialog editor seems badly broken on my HiDPI monitor (Lenovo ThinkVision 2880x1800 at 175%). It works fine on two other computers with standard monitors.
The dialogs get resized apparently randomly, and controls do not move correctly when I try to edit them. When I try to align controls the dotted selection rectangle may move, but the control often does not (in the editor). Sometimes, re-opening the editor shows that the control has in fact moved. When I build the project, the final display layout cannot be predicted from what appears in the resource editor.
I reported this to Microsoft using Visual Studio feedback, but they closed the report, saying it was "By design"!!!! They posted a link describing a feature which disables HiDPI awareness, but the link was for the Windows Forms Designer, not the MFC resource editor - there is no equivalent feature in the latter that I could find.
Does anyone else have this problem, or know of a decent work-around? At the moment I am transferring to my other computer with the standard display whenever I need to edit a dialog, which is monumentally inefficient for quite a large project.
I know this is an older post, but I thought what I found might help someone. I experienced the same issue today. It just happens that I have one monitor setup for 125% and one setup for 100%. The MFC dialog editor alignment operations do not work correctly on the 125% monitor but work fine on the 100% monitor. It would appear Microsoft isn't properly handling DPI in the dialog editor.
I am using Visual Studio Community 2017 and am frequently switching between several class files. The way I am having to do this is by pressing Ctrl+Tab (or Ctrl+Shift+Tab) repeatedly until I reach the desired tab.
It would be more convenient if there was a way to switch between tabs by pressing Ctrl+(tab's index) similar to how browser tabs are navigated. e.g. pressing Ctrl+1 opens the first/leftmost tab on your browser, Ctrl+2 opens the second one, etc.
Looking in Tools > Options > Environment > Keyboard, there are commands that use View.NavigateBackward and View.NavigateForward (The Ctrl+Tab and Ctrl+Shift+Tab functionality) that can be re-mapped - however nothing for the functionality I described above.
There are threads solving this issue for Visual Studio Code, however (and I'm really surprised/must be really dumb that) there are no threads that I could find for just Visual Studio.
Threads for Visual Studio Code:
Is there a quick change tabs function in Visual Studio Code?
https://github.com/Microsoft/vscode/issues/24753
You can switch to a specific tab with a keyboard shortcut with my Tabs Studio extension:
And you can additionally enable the Show tab numbers option to simplify usage of NavigateToTabXX commands:
So... After doing a more sensible search on StackOverflow instead of Google, I've found this thread;
https://stackoverflow.com/search?q=CTRL+Number+Visual+Studio
Which suggested to download a Visual Studio tool called "Hot Tabs". I have done so and it's working well for my purposes at the moment.
Hot Tabs
I've just updated to Visual Studio 2017 (15.8.2) - after the update, intellisense when debugging isn't working. For example, if I hover over abc (screen shot) I get the same summary as shown in the Locals (abc count=7), however I can't expand the tooltip to show the property's of the object - as shown in the Locals.
Also when I hit a breakpoint and the scroll to another part of the file, I automatically get taken back to the breakpoint after a few seconds.
These could be settings that were turned on as part of the update, however I haven't been able to find any info on this. I've also reset all settings however I still experience the same issues.
Update:
After some further searching I came across this https://developercommunity.visualstudio.com/content/problem/321198/variable-datatips-dont-expand.html
Looks like an issue introduced in 15.8.1
Windows 7 x64; MS Visual Studio 2010 SP1.
I press the F10 key step by step into DEBUG mode, and look the "Autos" window items. I see some variables (in the "Autos" window) sometime appears/disappears in their visibility area (and they are already initialized). Why it happen? Look the screens below.
The Autos window shows things the debugger thinks you may be interested in relation to where you are in the code. It's automagic, so it's impossible to explain exactly what the logic is. Use locals or watch windows if you need to have a more constant view.
When I start the program, I get the dialog and everything. But it closes by itself after some 10 seconds. How do I disable that?
EDIT: This happens when I run "Debug -> Start Without Debugging". This is the only way I know how to run the program.
EDIT2: My dialog is inheriting from CDialogEx.
If your dialog is not modal, i.e. you are not firing it up using the DoModal() member function, it is possible that it is being created with the constructor, and deleted with the destructor as it goes out of scope. You see this type of behaviour with some implementations of splash screens. To figure out what is happening, put a breakpoint on your dialogs destructor, and look at the call stack that is leading to it. It is also worth turning on all exceptions in the debugger, as you could be getting hit with an uncaught exception that is terminating your app.
As others have already said, this is not normal behaviour for an MFC app.
Usually dialogs do not behave that way.
But in default, they close on OnOk (CDialog::OnOk) which is "Enter Key Pressed"
and OnCancel (CDialog::OnCancel()) which is "Esc Key Pressed"
Try overloading those two in your Dialog, to see if those get called and to handle
the behaviour there as you like it.
Perhaps the Close event should also be handled or watched.
here are lots of examples of what can be done with a Dialog (especially OnOk, OnCancel and Close) CDialog Examples
I was facing the same issue with Visual Studio 2013:
I was creating the most basic MFC application with the Visual Studio wizard (either dialog-based, Single/Multiple document based), and just recompiling the generated code. No modification to the code at all.
I just found out that the "restart" does not occur when I turn off my Anti-virus. :-)
This is not a bug in Visual Studio, it is an environment problem.
My anti-virus is Avast.
The solution for Avast is to turn-off the Deepscreen feature.
There, go to Settings / Active Protection / Deepscreen - and disable that.
More details could be found about this approach to the solution on Avast's forums, from this discussion:
https://forum.avast.com/index.php?topic=139935.0
Confirmed, this happens with Visual Studio 2010, and doesn't happen with Visual Studio 2008. That means all the negative votes were completely unnecessary. It's a default of Visual Studio 2010, I didn't change anything. Nor did I make any bug, because I explicitly said that I created a new application without changing anything.
Thanks for all the negative votes.
Just for the record, I tried this using Visual Studio 2010. I picked Dialog-based application and left all the other options at their default settings. Compiled both Debug and Release configurations, for x86 and x64. When launched using Start without Debugging none of the four executables terminated by themselves.
If this is happening for you I would assume you have some application running (in the background) that interferes with the expected behavior. Try setting up a virtual machine, install a clean Visual Studio and perform the same procedure again.