DPI awareness manager questions 1

[Chris Miller]

I want to continue the discussion from the previous thread thread184-1821304

Summary
I would first like to summarize what I think is best to do with lower effort and when to go "full in" with all efforts to make an application dpi aware.

First, to summarize what I see in FoxyPreviewer is not using the fast/simple solution call SetProcessDPIAware(). But I do see the benefit of this simplest solution, as it also adjusts report sizing, it seems. Is that right, Mike?

I think the major point is that in GDI+ printers the printer is just another device context and what's printed is rendered with the same graphics routines as on screeen, that's perhaps why Microsoft decided to let the scale factor also scale reports, I wonder about that decision, as reports where in higher resolutions than screens even in the days of the first inkjet printers and surely with laser printers, so why didn't you just keep this separate, Microsoft? At least it explains why SetProcessDPIAware() works.

If you programmed scaling of forms in your application anyway, to address different fullscreen resolutions even with the same display dpi values, I guess this simple and fast solution could be sufficient, as it means Windows won't interfere with your scaling and your scaling will also adjust font sizes, etc., if you did think about keeping the same impression of your overall forms.

Atlopes DPIAwareManager (

https://github.com/atlopes/DPIAwareManager)

- that was also new to me - seems to go the same route as FoxyPreviewer, digging deeper into what current settings are with GetDeviceCaps.

Diving deeper into this topic I also found this:

https://learn.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context

From your GitHub readme I realize your manager is aiming for the awareness per-monitor, i.e. using multiple monitors with different dpi resolutions will be handled. I see that Windows even introduces a v2 of this in that enumeration.

Question
What about the scaling of forms while they are half on one monitor and half on another? Wouldn't that need two forms with everything duplicated? I guess it doesn't go as far but handles a form according to which monitor settings are relevant at its top/left position, right?
Do you handle this in the latest way DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 or DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE?

I know, I could look into your code, but I wanted to ask this on the forum because V2 seems like a new level in this game overall.

Chriss

 

[atlopes]

Chris, trying to answer your questions:

What about the scaling of forms while they are half on one monitor and half on another? Wouldn't that need two forms with everything duplicated? I guess it doesn't go as far but handles a form according to which monitor settings are relevant at its top/left position, right?

Forms can be rendered on different monitors simultaneously using a single scale. The DPIAwareManager gets the information on the monitor associated with each top-level form from Windows and adjusts its contents to any scale change (either by growing or shrinking). If the user moves a form from one monitor to another by dragging it with the mouse, the scaling will occur when the target monitor hosts most of the form surface.

Do you handle this in the latest way DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 or DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE?

DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 (I hope...).

 

[Chris Miller]

Thanks,

just one note:
Minimum supported client is Windows 10, version 1607.

Also, according to

https://learn.microsoft.com/en-us/w...ser/nf-winuser-setprocessdpiawarenesscontext:

Minimum supported client Windows 10, version 1703

And, according to

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setthreaddpiawarenesscontext

Minimum supported client Windows 10, version 1607

So I think it must be considered by Windows version, which awareness you can support. Does this also mean these are minimum required OS versions for your manager?

Chriss

 

[Chris Miller]

I think this is the best to use in the embedded manifest, according to

https://learn.microsoft.com/en-us/w...i-awareness-for-a-process?redirectedfrom=MSDN

...
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="[URL unfurl="true"]http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>[/URL]
      <dpiAwareness xmlns="[URL unfurl="true"]http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>[/URL]
    </asmv3:windowsSettings>
  </asmv3:application>
...

They only use true instead of true/pm for the older dpiAware setting for older Windows versions, maybe true/pm is desirable only if the minimum OS is Windows 8.1, Vista only supports "true" for system awaareness (not per monitor).

Since _vfp and _screen are always present, per this documentation calls of SetProcessDPIAware() and similar should always be too late. I guess that advice can be ignored, as it is works. On the other hand manifest embedding therefore is recommendable, isn't it?

Chriss

 

[atlopes]

Chris, just a quick reply before going off to work: including a manifest is the proper way to (start to) address the problem.

As Microsoft designed it, the manifest has a series of fallbacks to adjust the process to the system's capabilities. The repository's wiki presents a basic manifest to be used by a VFP application (see

https://github.com/atlopes/DPIAwareManager/wiki/Manage-an-application).

I'll return here later in case the thread triggers other questions.

 

[Mike Lewis]

what I see in FoxyPreviewer is not using the fast/simple solution call SetProcessDPIAware(). But I do see the benefit of this simplest solution, as it also adjusts report sizing, it seems. Is that right, Mike?

I think so. The "fast/simple solution" solved the problem for me for one particular user. Since then, I have switched to FoxyPreviewer for all my apps, after which I have never bothered to explicitly call SetProcessDPIAware().

If for any reason I couldn't use FoxyPreviewer, I would probably defintely go for António's DPIAwareManager.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Oh, I didn't want to make the impression the manifest is enough. If you're after support of multiple monitors with different DPI pixel densities, it's clear there must be a shift of scaling, when a form is moved from one to another monitor, and that's not done by Windows alone, that also needs to be triggered by an event, and as far as I can see there's the WM_DPIChanged windows message for that, available since Windows 8.1

At this point I should really just dive into what you're actually doing in your code and answer this from there. I'm just a bit flooded from what I find and have to sort it all out.

Chriss