Moving development from 100% Windows scaling to 150% chops WinForms window
I use C# Winforms in Visual Studio 2010. Since I've upgraded my laptop from the old 1366 x 768 resolution laptop to a new laptop with a 1920x1080 resolution, I noticed a problem when continuing development on the new laptop. I isolated the issue down to the new 150% Windows OS-wide scaling (Windows on the old laptop used 100% scaling). When I run the program, the right side of the window is strangely chopped off.
Here's the working version on the old laptop (1000 pixels wide, or 1500 pixels in 150% scaled Windows mode):
And here's the new version on the new laptop with the chopped window (1286 pixels wide, when it should be 1500 due to the 150% scaling).
Upon immediately loading the project into the new 150% scaled Windows setup and running the program, it appears to work fine, but as soon as you move one of the buttons so that VS updates the designer code (button 5 was moved as you can see), and then run, the window is chopped.
Even when manually going into the Form1.Designer.cs code, and adjusting the ClientSize to a stupid high horizontal value like ClientSize = new System.Drawing.Size(3000, 709); results in a window width that is limited to 1286 pixels at most. (Not so) coincidentally, 1286 is around 1920 / 1.5.
Basically, what the heck is going on? This appears like a bug with VS's scaling management. To be clear, the problem occurs when moving development from a 100% Windows scaled screen to a 150% Windows scaled screen, on any system. You don't need two laptops to reproduce the problem, it can all be reproduced on a single laptop (but make sure you log out and into Windows after switching from/to 100% or 150%).
Finally, to be clear, I know about setting the DPI-aware setting to true using an app.manifest file. Although this allows clearer text and solves the chopped window problem, I do NOT want to go this route due to inconsistent changes in my program's GUI such as overlapping controls and misplaced items on some setups.
c# winforms visual-studio-2010 scaling dpi
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
|
show 8 more comments
I use C# Winforms in Visual Studio 2010. Since I've upgraded my laptop from the old 1366 x 768 resolution laptop to a new laptop with a 1920x1080 resolution, I noticed a problem when continuing development on the new laptop. I isolated the issue down to the new 150% Windows OS-wide scaling (Windows on the old laptop used 100% scaling). When I run the program, the right side of the window is strangely chopped off.
Here's the working version on the old laptop (1000 pixels wide, or 1500 pixels in 150% scaled Windows mode):
And here's the new version on the new laptop with the chopped window (1286 pixels wide, when it should be 1500 due to the 150% scaling).
Upon immediately loading the project into the new 150% scaled Windows setup and running the program, it appears to work fine, but as soon as you move one of the buttons so that VS updates the designer code (button 5 was moved as you can see), and then run, the window is chopped.
Even when manually going into the Form1.Designer.cs code, and adjusting the ClientSize to a stupid high horizontal value like ClientSize = new System.Drawing.Size(3000, 709); results in a window width that is limited to 1286 pixels at most. (Not so) coincidentally, 1286 is around 1920 / 1.5.
Basically, what the heck is going on? This appears like a bug with VS's scaling management. To be clear, the problem occurs when moving development from a 100% Windows scaled screen to a 150% Windows scaled screen, on any system. You don't need two laptops to reproduce the problem, it can all be reproduced on a single laptop (but make sure you log out and into Windows after switching from/to 100% or 150%).
Finally, to be clear, I know about setting the DPI-aware setting to true using an app.manifest file. Although this allows clearer text and solves the chopped window problem, I do NOT want to go this route due to inconsistent changes in my program's GUI such as overlapping controls and misplaced items on some setups.
c# winforms visual-studio-2010 scaling dpi
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
You may want to consider using a TableLayoutPanel to position the buttons instead of absolute positions. That solves problems like this.
– Scott Chamberlain
Nov 21 '18 at 19:47
@ScottChamberlain: For the main issue, it's the size of the window that is truncated, rather than a problem with the positions of the controls.
– Dan W
Nov 21 '18 at 19:49
Everything is anchored to the top left. Either you need to anchor to the correct side (top right, bottom left, ect. The middle 3 will still be a problem though) or use a grid so the anchor points move with the form size.
– Scott Chamberlain
Nov 21 '18 at 19:51
1
The form gets scaled twice. First from 150% to 100% by the winforms plumbing. Then back up by the dpi virtualization of the OS. Scaling down is quite often problematic. The "chopped window" problem is caused by Winforms seeing the faked monitor size that the dpi virtualization provides. Your form has a design size that is too large for that. So it reduces the size to fit. Yes, you can call that a bug, it should apply the limit after scaling down. Not the only thing that can wrong, designing at 100% so it only ever scales up is certainly the most practical solution.
– Hans Passant
Nov 22 '18 at 12:15
1
There is no workaround. Not easy to fix for Microsoft either, that's why it isn't getting fixed. Keeping an eye on new framework releases is wise, all of the recent ones had dpi problem tweaks. But being able to switch VS2017 in dpi virtualization mode is a strong hint they threw up their hands btw, the down-scaling problems are pretty fundamental. Text needs proportionally more space at lower font point sizes, nasty.
– Hans Passant
Nov 22 '18 at 14:40
|
show 8 more comments
I use C# Winforms in Visual Studio 2010. Since I've upgraded my laptop from the old 1366 x 768 resolution laptop to a new laptop with a 1920x1080 resolution, I noticed a problem when continuing development on the new laptop. I isolated the issue down to the new 150% Windows OS-wide scaling (Windows on the old laptop used 100% scaling). When I run the program, the right side of the window is strangely chopped off.
Here's the working version on the old laptop (1000 pixels wide, or 1500 pixels in 150% scaled Windows mode):
And here's the new version on the new laptop with the chopped window (1286 pixels wide, when it should be 1500 due to the 150% scaling).
Upon immediately loading the project into the new 150% scaled Windows setup and running the program, it appears to work fine, but as soon as you move one of the buttons so that VS updates the designer code (button 5 was moved as you can see), and then run, the window is chopped.
Even when manually going into the Form1.Designer.cs code, and adjusting the ClientSize to a stupid high horizontal value like ClientSize = new System.Drawing.Size(3000, 709); results in a window width that is limited to 1286 pixels at most. (Not so) coincidentally, 1286 is around 1920 / 1.5.
Basically, what the heck is going on? This appears like a bug with VS's scaling management. To be clear, the problem occurs when moving development from a 100% Windows scaled screen to a 150% Windows scaled screen, on any system. You don't need two laptops to reproduce the problem, it can all be reproduced on a single laptop (but make sure you log out and into Windows after switching from/to 100% or 150%).
Finally, to be clear, I know about setting the DPI-aware setting to true using an app.manifest file. Although this allows clearer text and solves the chopped window problem, I do NOT want to go this route due to inconsistent changes in my program's GUI such as overlapping controls and misplaced items on some setups.
c# winforms visual-studio-2010 scaling dpi
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
I use C# Winforms in Visual Studio 2010. Since I've upgraded my laptop from the old 1366 x 768 resolution laptop to a new laptop with a 1920x1080 resolution, I noticed a problem when continuing development on the new laptop. I isolated the issue down to the new 150% Windows OS-wide scaling (Windows on the old laptop used 100% scaling). When I run the program, the right side of the window is strangely chopped off.
Here's the working version on the old laptop (1000 pixels wide, or 1500 pixels in 150% scaled Windows mode):
And here's the new version on the new laptop with the chopped window (1286 pixels wide, when it should be 1500 due to the 150% scaling).
Upon immediately loading the project into the new 150% scaled Windows setup and running the program, it appears to work fine, but as soon as you move one of the buttons so that VS updates the designer code (button 5 was moved as you can see), and then run, the window is chopped.
Even when manually going into the Form1.Designer.cs code, and adjusting the ClientSize to a stupid high horizontal value like ClientSize = new System.Drawing.Size(3000, 709); results in a window width that is limited to 1286 pixels at most. (Not so) coincidentally, 1286 is around 1920 / 1.5.
Basically, what the heck is going on? This appears like a bug with VS's scaling management. To be clear, the problem occurs when moving development from a 100% Windows scaled screen to a 150% Windows scaled screen, on any system. You don't need two laptops to reproduce the problem, it can all be reproduced on a single laptop (but make sure you log out and into Windows after switching from/to 100% or 150%).
Finally, to be clear, I know about setting the DPI-aware setting to true using an app.manifest file. Although this allows clearer text and solves the chopped window problem, I do NOT want to go this route due to inconsistent changes in my program's GUI such as overlapping controls and misplaced items on some setups.
c# winforms visual-studio-2010 scaling dpi
c# winforms visual-studio-2010 scaling dpi
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
edited Nov 21 '18 at 23:31
Dan W
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
asked Nov 21 '18 at 19:39
Dan WDan W
1,41332754
1,41332754
You may want to consider using a TableLayoutPanel to position the buttons instead of absolute positions. That solves problems like this.
– Scott Chamberlain
Nov 21 '18 at 19:47
@ScottChamberlain: For the main issue, it's the size of the window that is truncated, rather than a problem with the positions of the controls.
– Dan W
Nov 21 '18 at 19:49
Everything is anchored to the top left. Either you need to anchor to the correct side (top right, bottom left, ect. The middle 3 will still be a problem though) or use a grid so the anchor points move with the form size.
– Scott Chamberlain
Nov 21 '18 at 19:51
1
The form gets scaled twice. First from 150% to 100% by the winforms plumbing. Then back up by the dpi virtualization of the OS. Scaling down is quite often problematic. The "chopped window" problem is caused by Winforms seeing the faked monitor size that the dpi virtualization provides. Your form has a design size that is too large for that. So it reduces the size to fit. Yes, you can call that a bug, it should apply the limit after scaling down. Not the only thing that can wrong, designing at 100% so it only ever scales up is certainly the most practical solution.
– Hans Passant
Nov 22 '18 at 12:15
1
There is no workaround. Not easy to fix for Microsoft either, that's why it isn't getting fixed. Keeping an eye on new framework releases is wise, all of the recent ones had dpi problem tweaks. But being able to switch VS2017 in dpi virtualization mode is a strong hint they threw up their hands btw, the down-scaling problems are pretty fundamental. Text needs proportionally more space at lower font point sizes, nasty.
– Hans Passant
Nov 22 '18 at 14:40
|
show 8 more comments
You may want to consider using a TableLayoutPanel to position the buttons instead of absolute positions. That solves problems like this.
– Scott Chamberlain
Nov 21 '18 at 19:47
@ScottChamberlain: For the main issue, it's the size of the window that is truncated, rather than a problem with the positions of the controls.
– Dan W
Nov 21 '18 at 19:49
Everything is anchored to the top left. Either you need to anchor to the correct side (top right, bottom left, ect. The middle 3 will still be a problem though) or use a grid so the anchor points move with the form size.
– Scott Chamberlain
Nov 21 '18 at 19:51
1
The form gets scaled twice. First from 150% to 100% by the winforms plumbing. Then back up by the dpi virtualization of the OS. Scaling down is quite often problematic. The "chopped window" problem is caused by Winforms seeing the faked monitor size that the dpi virtualization provides. Your form has a design size that is too large for that. So it reduces the size to fit. Yes, you can call that a bug, it should apply the limit after scaling down. Not the only thing that can wrong, designing at 100% so it only ever scales up is certainly the most practical solution.
– Hans Passant
Nov 22 '18 at 12:15
1
There is no workaround. Not easy to fix for Microsoft either, that's why it isn't getting fixed. Keeping an eye on new framework releases is wise, all of the recent ones had dpi problem tweaks. But being able to switch VS2017 in dpi virtualization mode is a strong hint they threw up their hands btw, the down-scaling problems are pretty fundamental. Text needs proportionally more space at lower font point sizes, nasty.
– Hans Passant
Nov 22 '18 at 14:40
You may want to consider using a TableLayoutPanel to position the buttons instead of absolute positions. That solves problems like this.
– Scott Chamberlain
Nov 21 '18 at 19:47
You may want to consider using a TableLayoutPanel to position the buttons instead of absolute positions. That solves problems like this.
– Scott Chamberlain
Nov 21 '18 at 19:47
@ScottChamberlain: For the main issue, it's the size of the window that is truncated, rather than a problem with the positions of the controls.
– Dan W
Nov 21 '18 at 19:49
@ScottChamberlain: For the main issue, it's the size of the window that is truncated, rather than a problem with the positions of the controls.
– Dan W
Nov 21 '18 at 19:49
Everything is anchored to the top left. Either you need to anchor to the correct side (top right, bottom left, ect. The middle 3 will still be a problem though) or use a grid so the anchor points move with the form size.
– Scott Chamberlain
Nov 21 '18 at 19:51
Everything is anchored to the top left. Either you need to anchor to the correct side (top right, bottom left, ect. The middle 3 will still be a problem though) or use a grid so the anchor points move with the form size.
– Scott Chamberlain
Nov 21 '18 at 19:51
1
1
The form gets scaled twice. First from 150% to 100% by the winforms plumbing. Then back up by the dpi virtualization of the OS. Scaling down is quite often problematic. The "chopped window" problem is caused by Winforms seeing the faked monitor size that the dpi virtualization provides. Your form has a design size that is too large for that. So it reduces the size to fit. Yes, you can call that a bug, it should apply the limit after scaling down. Not the only thing that can wrong, designing at 100% so it only ever scales up is certainly the most practical solution.
– Hans Passant
Nov 22 '18 at 12:15
The form gets scaled twice. First from 150% to 100% by the winforms plumbing. Then back up by the dpi virtualization of the OS. Scaling down is quite often problematic. The "chopped window" problem is caused by Winforms seeing the faked monitor size that the dpi virtualization provides. Your form has a design size that is too large for that. So it reduces the size to fit. Yes, you can call that a bug, it should apply the limit after scaling down. Not the only thing that can wrong, designing at 100% so it only ever scales up is certainly the most practical solution.
– Hans Passant
Nov 22 '18 at 12:15
1
1
There is no workaround. Not easy to fix for Microsoft either, that's why it isn't getting fixed. Keeping an eye on new framework releases is wise, all of the recent ones had dpi problem tweaks. But being able to switch VS2017 in dpi virtualization mode is a strong hint they threw up their hands btw, the down-scaling problems are pretty fundamental. Text needs proportionally more space at lower font point sizes, nasty.
– Hans Passant
Nov 22 '18 at 14:40
There is no workaround. Not easy to fix for Microsoft either, that's why it isn't getting fixed. Keeping an eye on new framework releases is wise, all of the recent ones had dpi problem tweaks. But being able to switch VS2017 in dpi virtualization mode is a strong hint they threw up their hands btw, the down-scaling problems are pretty fundamental. Text needs proportionally more space at lower font point sizes, nasty.
– Hans Passant
Nov 22 '18 at 14:40
|
show 8 more comments
1 Answer
1
active
oldest
votes
I've found two half-solutions so far:
First is upgrading to Visual Studio 2017 (which allows you to force 100% scaling in VS Forms designer even in 150% Windows scaling)
Second is keeping with an earlier version of Visual Studio (including VS 2010), but making sure Windows is set to 100% scaling. If you've only just changed the scaling setting, make sure to log out and in of Windows to ensure the scaling is applied appropriately.
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53419413%2fmoving-development-from-100-windows-scaling-to-150-chops-winforms-window%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I've found two half-solutions so far:
First is upgrading to Visual Studio 2017 (which allows you to force 100% scaling in VS Forms designer even in 150% Windows scaling)
Second is keeping with an earlier version of Visual Studio (including VS 2010), but making sure Windows is set to 100% scaling. If you've only just changed the scaling setting, make sure to log out and in of Windows to ensure the scaling is applied appropriately.
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
add a comment |
I've found two half-solutions so far:
First is upgrading to Visual Studio 2017 (which allows you to force 100% scaling in VS Forms designer even in 150% Windows scaling)
Second is keeping with an earlier version of Visual Studio (including VS 2010), but making sure Windows is set to 100% scaling. If you've only just changed the scaling setting, make sure to log out and in of Windows to ensure the scaling is applied appropriately.
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
add a comment |
I've found two half-solutions so far:
First is upgrading to Visual Studio 2017 (which allows you to force 100% scaling in VS Forms designer even in 150% Windows scaling)
Second is keeping with an earlier version of Visual Studio (including VS 2010), but making sure Windows is set to 100% scaling. If you've only just changed the scaling setting, make sure to log out and in of Windows to ensure the scaling is applied appropriately.
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
I've found two half-solutions so far:
First is upgrading to Visual Studio 2017 (which allows you to force 100% scaling in VS Forms designer even in 150% Windows scaling)
Second is keeping with an earlier version of Visual Studio (including VS 2010), but making sure Windows is set to 100% scaling. If you've only just changed the scaling setting, make sure to log out and in of Windows to ensure the scaling is applied appropriately.
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
answered Nov 22 '18 at 11:17
Dan WDan W
1,41332754
1,41332754
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53419413%2fmoving-development-from-100-windows-scaling-to-150-chops-winforms-window%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You may want to consider using a TableLayoutPanel to position the buttons instead of absolute positions. That solves problems like this.
– Scott Chamberlain
Nov 21 '18 at 19:47
@ScottChamberlain: For the main issue, it's the size of the window that is truncated, rather than a problem with the positions of the controls.
– Dan W
Nov 21 '18 at 19:49
Everything is anchored to the top left. Either you need to anchor to the correct side (top right, bottom left, ect. The middle 3 will still be a problem though) or use a grid so the anchor points move with the form size.
– Scott Chamberlain
Nov 21 '18 at 19:51
1
The form gets scaled twice. First from 150% to 100% by the winforms plumbing. Then back up by the dpi virtualization of the OS. Scaling down is quite often problematic. The "chopped window" problem is caused by Winforms seeing the faked monitor size that the dpi virtualization provides. Your form has a design size that is too large for that. So it reduces the size to fit. Yes, you can call that a bug, it should apply the limit after scaling down. Not the only thing that can wrong, designing at 100% so it only ever scales up is certainly the most practical solution.
– Hans Passant
Nov 22 '18 at 12:15
1
There is no workaround. Not easy to fix for Microsoft either, that's why it isn't getting fixed. Keeping an eye on new framework releases is wise, all of the recent ones had dpi problem tweaks. But being able to switch VS2017 in dpi virtualization mode is a strong hint they threw up their hands btw, the down-scaling problems are pretty fundamental. Text needs proportionally more space at lower font point sizes, nasty.
– Hans Passant
Nov 22 '18 at 14:40