Different DPI on Windows 10 causes screen capture overlay to display incorrectly

[VictorZakharov]

trafficstars

On Windows 10 if each monitor is using different DPI, screen capture window takes portion of the screen (limitation of existing design, will need to rework so that each monitor is covered by its own screen capture dialog).

[VictorZakharov]

I spent a few hours on this and could not figure out. Problem is setting capture window as topmost dialog for multiple windows at the same time. You cannot have multiple modal dialogs at the same time. So it has to be one form, which is correctly stretched to accommodate full desktop, accounting for different DPI, I'm not sure how to accomplish this. Tagged ticket with "help wanted".

Greenshot somehow does it, so might need to spend more time looking into their source (it's also open source .NET code). Upvote if you think it's important. Personally I run all my monitors with the same DPI setting. They all (4) have the same size (24'') and orientation (landscape) - easier to work with.

[RamonUnch]

Sorry to bump an old thread but I do have some food for though here.

It seems from looking at your source that you did not declare your program to be per-monitor DPI aware and just used the SetProcessDPIAware function. So all monitors are falsely scaled to the primary monitor DPI and when you manipulate coordinates in pixels, all the values are scaled and you get troubles. The SetProcessDPIAware is only good for Windows Vista/7 when no per-monitor DPI existed.

If you always reason in pixels, then your program should declare itself as per monitor DPI aware. This can be done using the SetProcessDPIAware(PROCESS_PER_MONITOR_DPI_AWARE = 2) on Win8.x or by using SetProcessDpiAwarenessContext() on Win10 1607+ or something like this, when Microsoft introduced the version two of per-monitor dpi awareness.

I would recommend not to mess up with those functions but rather to add the following lines in your .manifest file.

<asmv3:application>
  <asmv3:windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>
  </asmv3:windowsSettings>
</asmv3:application>

This is what Microsoft recommends. https://docs.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process

Also once your program is declared as fully DPI-aware, you will be able to use the GetDpiForWindow and GetDpiForMonitor and they will no more lye to you.

[VictorZakharov]

@RamonUnch That's an interesting idea. Unfortunately, per-monitor DPI aware behavior requires at least .NET 4.6.2, according to this answer. This project is based on .NET 4.0 for wider compatibility between Windows version. It can even run on Windows XP!

Another point - I am not using WPF, which is what most examples are using, for instance:

• https://github.com/Microsoft/WPF-Samples/tree/master/PerMonitorDPI

[RamonUnch]

You can always change the .manifest file with a resource editor once your project is compiled. there is no reasons .NET version would matter. The manifest file is just a resource attached to your exe completely language neutral. It would remain XP compatible no problems.

You can also on newer Winodw force the DPI awareness for any program in the compatibility property sheet of the program/shortcut.

[RamonUnch]

Well sorry, I did not think properly but you are right because .NET has his own procedures to draw controls, So this one might not be DPI aware and the program might have problems if you force per monitor DPI awareness. This could still be tried though.

[VictorZakharov]

I'll think about it, thanks.