Resolved Resizing Visual Studio 2019 main window

[cbreemer]

Hi all,
New member here. I hope my first post is appropriate for this forum.
I am using Microsoft Visual Studio Community 2019, Version 16.10.3, and find it very hard to resize the main window with the mouse. The resize border is very narrow, only a couple of pixels it seems, making it quite an effort to get the resize cursor to appear. I don't have this issue with any other Windows program, and I never had it with previous VS versions. Does anyone else have this problem, and perhaps know a way to solve it ?
TIA,
Chris

 

[jmcilhinney]

I'm on Windows 11 and I just tested VS 2019 and, as far as I can tell, the border is 7 pixels wide. The visible border is far narrower than that but the resize cursor is displayed for several pixels outside that visible border, because the logical window has a much wider border. Actually, I just tested the Your Phone app and its border seems to be several pixels narrower. I have most windows maximised and pretty much always have VS maximised or docked, so I rarely use the border for resizing, but it doesn't seem like it should be an issue unless you have an unsteady hand. Regardless, there is a resizing handle in the bottom-right corner that should have a greater area for grabbing so, if you are having trouble for some reason, you may find it easier to use that. You would need to move the window as well, if you wanted to resize up or left, but that's not much trouble.

Keep in mind that you can use Windows+arrow key combinations to dock a window to the right or left half of a screen, so that may make things easier if that's the sort of configuration you want. The Fancy Zones tool in the PowerToys app gives you greater control too. If you're using Windows 11, hovering over the maximise button of a window gives you various options for docking a window as part of a group. Any of those options might reduce your need to manually resize windows a bit.

 

[Skydiver]

It was kind of interesting running Spy++ on VS2019. The window rect and client rect were exactly the same. I'm so used to seeing classic Windows apps where the client rect is inset on the window rect.

Anyway, I'm seeing the same behavior as @jmcilhinney : looks to be about 7-8 pixel wide area.

Is there a chance that you are using a high DPI display? Or did you set your font scaling to something below 100%?

 

[cbreemer]

I'm on Windows 11 and I just tested VS 2019 and, as far as I can tell, the border is 7 pixels wide. The visible border is far narrower than that but the resize cursor is displayed for several pixels outside that visible border, because the logical window has a much wider border. Actually, I just tested the Your Phone app and its border seems to be several pixels narrower. I have most windows maximised and pretty much always have VS maximised or docked, so I rarely use the border for resizing, but it doesn't seem like it should be an issue unless you have an unsteady hand. Regardless, there is a resizing handle in the bottom-right corner that should have a greater area for grabbing so, if you are having trouble for some reason, you may find it easier to use that. You would need to move the window as well, if you wanted to resize up or left, but that's not much trouble.

Keep in mind that you can use Windows+arrow key combinations to dock a window to the right or left half of a screen, so that may make things easier if that's the sort of configuration you want. The Fancy Zones tool in the PowerToys app gives you greater control too. If you're using Windows 11, hovering over the maximise button of a window gives you various options for docking a window as part of a group. Any of those options might reduce your need to manually resize windows a bit.

Thanks for your elaborate reply ! Much appreciated. Haha no, I don't have an unsteady hand I get the job done and it's not a big deal. It's just mildly annoying and inconsistent, and I hate inconsistency. It bugs me that VS2019 is the ONLY program ever to be like this. And apparently mostly ONLY for me, not others (although there was one person on another forum who had the same issue). I tried Your Phone and that is fine, a nice wide resize margin (if I can call it that). Perhaps MS reckoned that everybody would always have VS maximized or docked... but I often like seeing several windows at once. Oh well...

 

[cbreemer]

It was kind of interesting running Spy++ on VS2019. The window rect and client rect were exactly the same. I'm so used to seeing classic Windows apps where the client rect is inset on the window rect.

Anyway, I'm seeing the same behavior as @jmcilhinney : looks to be about 7-8 pixel wide area.

Is there a chance that you are using a high DPI display? Or did you set your font scaling to something below 100%?

Many thanks for your feedback ! Spy++ confuses me here. For many applications (e.g. Command window, Textpad) it does not show a main window border. For others (e.g. Chrome, Foxit Reader, VS2019) it does. Yet all programs (except VS2019) can be easily resized. I have a default 1920x1180 display, no font scaling or other settings applied. Isn't it strange !

 

[Skydiver]

Are you using the standard Windows mouse driver, or are you using a custom mouse driver that came with your mouse (e.g. Logitech, Razor, Synaptics, etc.)?

For example, my Lenovo A485 came with some custom mouse driver that made my Logitech trackball skip like crazy even at the lowest mouse sensitivity settings. This obviously made targeting small areas like window chrome and column sizing headers difficult. I ended up uninstalling all mouse drivers, rebooting, and then let the Windows Plug n' Play install the default Windows mouse/touchpad driver. Things worked well for a few weeks until the Lenovo bloatware for updating drivers kicked in and insisted on installing their mouse driver again. Needless to say, I disabled that bloatware and then did the strip down the mouse drivers again trick.

 

[cbreemer]

Are you using the standard Windows mouse driver, or are you using a custom mouse driver that came with your mouse (e.g. Logitech, Razor, Synaptics, etc.)?

For example, my Lenovo A485 came with some custom mouse driver that made my Logitech trackball skip like crazy even at the lowest mouse sensitivity settings. This obviously made targeting small areas like window chrome and column sizing headers difficult. I ended up uninstalling all mouse drivers, rebooting, and then let the Windows Plug n' Play install the default Windows mouse/touchpad driver. Things worked well for a few weeks until the Lenovo bloatware for updating drivers kicked in and insisted on installing their mouse driver again. Needless to say, I disabled that bloatware and then did the strip down the mouse drivers again trick.

I have a Bluetooth Logitech keyboard and mouse, and the mouse uses the Logitech driver. It's smooth as silk though, so I don't think that is the problem. Also, it's not the mouse who decides when to show the resize cursor, it's Windows doing that. At least I think that is the case

 

[Skydiver]

If the app had a client rect smaller than the window rect, then yes, it's Windows that decides the resize cursor if the app doesn't handle the non-client mouse messages. In the case of VS2019 were it's client rect completely fills the window rect, the app chooses when to show the resize cursor because it's all client area.

In both cases though, either Windows or the app is completely dependent on the data provided by the mouse driver as to the relative position of the mouse since the last mouse movement. If bad position data is being sent, then it's a matter of garbage in-garbage out.

 

[cbreemer]

If the app had a client rect smaller than the window rect, then yes, it's Windows that decides the resize cursor if the app doesn't handle the non-client mouse messages. In the case of VS2019 were it's client rect completely fills the window rect, the app chooses when to show the resize cursor because it's all client area.

In both cases though, either Windows or the app is completely dependent on the data provided by the mouse driver as to the relative position of the mouse since the last mouse movement. If bad position data is being sent, then it's a matter of garbage in-garbage out.

Sounds reasonable ! I'm sure you are right. But I'm also sure the mouse is not to blame here. Because it has never, ever, put one foot wrong - despite it working via Bluetooth. Ah well, don't spend any more time on this. I'll accept it as one of Windows' mysteries, and learn to live with it. Thanks for your time

 

[Skydiver]

Given VS' history of UI issues when they transitioned from Win32 API to WPF, I would not be surprised that they may have some hit-testing bugs for changing the mouse cursor to the resize cursor at the appropriate time.

 

[JohnH]

I almost always maximize VS too, just tested resizing today. I currently have both VS 2019 and 2022 installed on both Windows 10 and 11. In Windows 10 resolution (1680x1050 no scale) sizing appeared normal for both VS, in Windows 11 (1920x1080 no scaling) VS 2019 is normal, but VS 2022 has very narrow sizing (managable). Both mouse configured in Windows with fast pointer movement and not enabled enhanced pointer precision (due to multiple screens). Mouse sensitivity (DPI or CPI) can affect the relative screen/physical pointer movement too, if you can configure this lower DPI means better control (less screen movement for physical movement). I have a 1000 DPI mouse on Win10 and a configurable mouse set to 1600 DPI on Win11.

 

[cbreemer]

Given VS' history of UI issues when they transitioned from Win32 API to WPF, I would not be surprised that they may have some hit-testing bugs for changing the mouse cursor to the resize cursor at the appropriate time.

Yes, it could well be some arcane bug related to my particular hard-or software. I just upgraded from 16.10.3 to 16.11.7 but it hasn't helped. Oh well.

 

[cbreemer]

I almost always maximize VS too, just tested resizing today. I currently have both VS 2019 and 2022 installed on both Windows 10 and 11. In Windows 10 resolution (1680x1050 no scale) sizing appeared normal for both VS, in Windows 11 (1920x1080 no scaling) VS 2019 is normal, but VS 2022 has very narrow sizing (managable). Both mouse configured in Windows with fast pointer movement and not enabled enhanced pointer precision (due to multiple screens). Mouse sensitivity (DPI or CPI) can affect the relative screen/physical pointer movement too, if you can configure this lower DPI means better control (less screen movement for physical movement). I have a 1000 DPI mouse on Win10 and a configurable mouse set to 1600 DPI on Win11.

Thanks for testing this out JohnH. Seems like you have the same thing on Windows 11 with VS2022 ! Don't you just wonder why that would be ?
But as I replied to SkyDiver, I don't think the mouse or its settings are to blame here. And even if it were, I'd rather live with this small inconvenience than fiddle with my mouse settings and bugger up everything else that works just fine now. At my age, I resist change as much as possible

 

[cbreemer]

I found out this issue had already been reported in april 2021:
Visual Studio Feedback

but there are only 3 votes for it (including mine). Somehow I do not have high hopes it will be fixed.

 

[cbreemer]

UPDATE: I found this issue to be fixed in VS Community 2022 version 17.0.4. Oh joy