T O P I C R E V I E W |
MrJones4u |
Posted - Oct 29 2015 : 10:01:45 AM After updating to windows 10 the font size of VA suggestion window follows the DPI setting of a different window. In my 5 screen setup I have one screen that, for the sake of readability has to be set at 125%.
Screen 4 is my VS editor window (100%) and screen 5 is my secondary VS screen (125%) used for compiler output, call stack, find results and similar.
Now, whenever I, on my primary screen, trigger a VA suggestion window e.g. using ALT-G or ALT-M the list is overly large and especially the ALT-M becomes almost unusably as the top lines stick of the screen at the top.
Changing screen 5's resolution back to 100% makes everything behave normal, yet then I cannot read anything on that display. Right up to the update to windows 10 none of this was a problem.
VA_X.dll file version 10.9.2076.0 built 2015.09.15
The screen with the 125%
The screen with the 100%
The ALT-M sticking out the top...
The ALT-G showning the oversized font...
|
10 L A T E S T R E P L I E S (Newest First) |
sean |
Posted - Aug 16 2017 : 01:37:50 AM case=93048 is fixed in build 2231 |
MrJones4u |
Posted - Jun 22 2016 : 02:29:56 AM Thanks for staying on the issue! |
sean |
Posted - Jun 21 2016 : 11:01:30 PM No progress on this except that we have an alternative workaround that addresses the bad scaling and positioning of windows/controls for both VS and VA that does not require the Compatibility troubleshooter (rerun it for devenv.exe and undo all fixes).
The bad behavior occurs when Windows sees that the most recently created floating window for the VS process is on one of the secondary monitors (and is still visible).
So we just need to give it cause to see a more recently created (and visible) floating window on the primary monitor. The Immediates Window (Debug | Windows | Immediate or ctrl+alt+i) can be set to floating and can be resized to a very small size. As long as you float that window last, Windows won't interfere with positioning and scaling. Any other window will work also, as long as it is set to floating -- but some of the toolwindows have minimum sizes that are too large.
After restarting VS, you may have to close the floating window and then re-open it.
|
sean |
Posted - Jan 12 2016 : 12:48:34 PM Not fixed -- just offered a workaround. I do not have much hope of a fix until VS itself works properly in such environments. |
MrJones4u |
Posted - Jan 12 2016 : 05:32:35 AM Yes, changing the displays DPI to 100% and adjusting the resolution so that it matches the previous set DPI will indeed �fix� the problem. But now the screen is upscaling and therefore everything is blurry whereas before the font would have been rendered bigger.
While not perfect this will work for the meantime� just please don�t call this fixed. |
sean |
Posted - Jan 06 2016 : 4:05:31 PM You mentioned that changing monitor 5 from 125% to 100% means you cannot read anything on that display. If only VS windows on that monitor were 100%, would that be of any help or would it effectively be the same as changing the entire monitor to 100%?
In my investigation I have noted that there a couple of controls in VS that also behave unexpectedly: the progress window, the completion list in the command window, the configuration dropdown in project properties. It appears to be a problem of some sort in the way that Windows treats dpiaware applications with windows on multiple monitors that have different dpi settings. The only way I have found to workaround the issue is to either not put VS windows on the monitor that uses a unique display percentage or disable DPI scaling for devenv via the compatibility troubleshooter.
Compatibility troubleshooter directions: In File Explorer, right-click on devenv.exe select Troubleshoot Compatibility in the dialog that appears, select the second option (Troubleshoot program) select: The program opens but doesn't display correctly select: Program does not display properly when large scale font settings are selected Next page states: Display settings: Scaling on high DPI select Test to try the workaround select Next select Yes, save these settings for this program
|
MrJones4u |
Posted - Oct 31 2015 : 06:07:20 AM Hello, the update was from Windows 7 and yes there is not specific way for changing the DPI per screen in windows 7, but you can change the resolution per screen and most screens can cope with mismatched resolutions - DPI adjustment for poor :-)
glad that you could reproduce it! cu |
accord |
Posted - Oct 30 2015 : 7:26:45 PM I installed Windows 10 and VS2015 on a VM, and was able to reproduce the problem. I have put in a bug report for this:
case=93048
Well, moving the output window was a good catch, it was the trigger for reproducing the problem. Thank you for the clear description of the problem. Thankfully, a dual-monitor setup was enough. |
feline |
Posted - Oct 30 2015 : 4:55:27 PM Which OS were you using before? Or am I misreading your comment:
>> Right up to the update to windows 10 none of this was a problem.
I am not seeing any way to set a display specific DPI in Windows 7 or 8.1.
If the problem was triggered by a recent Windows 10 update then this could get "interesting". I am currently looking to see if I have Windows 10 test systems with different update levels. |
MrJones4u |
Posted - Oct 30 2015 : 04:25:52 AM Just made some further tests: If the screen that has the VS2015 output windows on it, has a resolution different than 100% then VAX will display and align any popup window incorrectly on the other screens� If the output window is moved onto a screen that has a 100% resolution the next opened popup window is displayed correctly (no restart of VS or system required). Is it possible that VAX always creates the popup windows on the screen / location where the output windows is located and moves it to the required location � and windows does not resize it?
|