×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

DPI awareness manager questions

DPI awareness manager questions

DPI awareness manager questions

(OP)
I want to continue the discussion from the previous thread thread184-1821304: Why is my report zoomed?

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/hi...
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

RE: DPI awareness manager questions

Chris, trying to answer your questions:

Quote (Chris)

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.

Quote (Chris)

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

RE: DPI awareness manager questions

(OP)
Thanks,

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

Also, according to https://learn.microsoft.com/en-us/windows/win32/ap...:
Minimum supported client Windows 10, version 1703

And, according to https://learn.microsoft.com/en-us/windows/win32/ap...
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

RE: DPI awareness manager questions

(OP)
I think this is the best to use in the embedded manifest, according to https://learn.microsoft.com/en-us/windows/win32/hi...

CODE

...
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
    </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

RE: DPI awareness manager questions

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

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

RE: DPI awareness manager questions

Quote:

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

RE: DPI awareness manager questions

(OP)
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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close