Moving development from 100% Windows scaling to 150% chops WinForms window












0














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):



old



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).



new



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.










share|improve this question
























  • 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


















0














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):



old



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).



new



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.










share|improve this question
























  • 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
















0












0








0







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):



old



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).



new



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.










share|improve this question















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):



old



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).



new



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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 21 '18 at 23:31







Dan W

















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




















  • 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














1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer





















    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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.






    share|improve this answer


























      0














      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.






      share|improve this answer
























        0












        0








        0






        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 22 '18 at 11:17









        Dan WDan W

        1,41332754




        1,41332754






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            404 Error Contact Form 7 ajax form submitting

            How to know if a Active Directory user can login interactively

            TypeError: fit_transform() missing 1 required positional argument: 'X'