Windows 应用程序在调试时使用 Win32.MoveWindow 调整大小错误地缩放了 125%

Question

I use 2560x1440 monitors scaled on Windows 10 to 125%. I wrote a C# unit test case in Visual Studio 2019 that calls a DLL to 1) find the window handles of various apps (notepad, wordpad, etc) and 2) resize them to just under 100% of the monitor size. I used Win32.MoveWindow to do the move, like so:

//    MoveWindow(hWnd, left, top, width, height)
Win32.MoveWindow(hWnd, 0, 0, 2500, 1400, true);

The problem is that while debugging in the unit test, Windows10 scales up the 2500 and 1400 pixel numbers by 125% and moves the windows to that larger size. The windows then hang off the bottom and right edges of the screen.

In contrast, when I run the same DLL code from a skeleton Windows Forms app (and while not debugging), the code works fine, and Windows resizes the Notepad and Wordpad app windows correctly.

I pass in the same numbers to Win32.MoveWindow in both cases.

In case it matters, for the DLL code, I have tried endless combinations of the app.config and app.manifest settings for my DLL code that calls Win32.MoveWindow (and am targeting NET 4.7.2) but without success.

For the skeleton Forms app, I have tried 4.6.1 and 4.7.2 with no DPI settings in app.config and the "dpiAware=true" enabled in the app.manifest. (Of course, neither the skeleton Forms app nor the DLL are DPI aware. I just tried the setting on and off.)

The only thing that seems to make a difference is whether I am debugging. I expected that I could use the normal screen pixels from the OS screen boundaries when I did MoveWindow operations, but that isn't working well when debugging.

What is the proper way to resize other apps with Win32.MoveWindow ? Should my app determine the current scaling factor and then down-scale the numbers that I pass to Win32.MoveWindow ? (I would pass 2500/1.25 = 2000 to Win32.MoveWindow , for example, for 125% scaling.)

Is the debugger supposed to interfere with scaling and sizing like this? Is it a known problem?

Answer 1

@selbie was totally correct and exactly on the target with his comment. He was even kind enough to bold one of the key statement lines for me to draw my attention to it. @selbie made it easy for me to solve the problem. I have included my test code fragments below.

Windows Behavior

As @selbie pointed out, if 125% scaling is enabled in the Accessibility Settings to make everything bigger, Windows reports different screen sizes to aware and unaware processes.

For DPI-aware processes, Windows will report 2560x1440 because they are supposed to down-scale their thinking so that Windows can scale it back up 125% to produce sharp text, etc.

For DPI-unaware processes, Windows will report 2048x1152 to the caller so the caller thinks the screen is smaller than it really is. Windows scales up the caller's orders by 125% to make the caller's sizes fit the hardware screen size (2560x1440).

The Problem

The problem I had was that my unit test code (DPI unaware) was using the hardware sizes in my DLL code (2560x1440), obtained from a database and not the OS, so when Windows scaled it up, my relocated windows were bigger than the hardware screen size.

When the same DLL was used in a DPI-aware Forms app, Windows allowed for everything (produced no net scaling up) and the relocated windows fit the hardware screens.

The Solutions

The first solution is to make your calling process DPI-aware so that you can use the hardware screen sizes in your code. Do this by calling the Win32 API in NET 4.6 and above. This is what I used in my unit test to make it work properly.

[STAThread]
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern bool SetProcessDPIAware();

static void Main() {
    if (Environment.OSVersion.Version.Major >= 6) SetProcessDPIAware();
    ... either ConsoleApp code or Windows.Forms code here
}

The second solution is to enable DPI-awareness in the EXE app.manifest file. Just uncomment the default XML code in the default app.manifest file produced by AddNew in Visual Studio.

APP.MANIFEST FILE
<application xmlns = "urn:schemas-microsoft-com:asm.v3" >
  <windowsSettings >
  <dpiAware xmlns = "http://schemas.microsoft.com/SMI/2005/WindowsSettings" >
      true </dpiAware >
  </windowsSettings >
</application >

In NET 4.7 and above, you can also use the new PerMonitorV2 DPI settings in the app.config file, not the `app.manifest' file. This apparently lets you use different DPI-awareness for different monitors. (I have not tried this yet, but I mention it here for completeness.)

<configuration>
    <!--requires NET 4.7, and the default is false />
    <System.Windows.Forms.ApplicationConfigurationSection>
        <add key="DpiAwareness" value="PerMonitorV2" />
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="false" />
    </System.Windows.Forms.ApplicationConfigurationSection>
</configuration>