Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Toolkit Pro
  New Posts New Posts RSS Feed - Add support for "system enhanced scaling"
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Add support for "system enhanced scaling"

 Post Reply Post Reply
Author
Message
mnissl View Drop Down
Groupie
Groupie


Joined: 12 June 2018
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote mnissl Quote  Post ReplyReply Direct Link To This Post Topic: Add support for "system enhanced scaling"
    Posted: 23 August 2022 at 8:46am
In 2017, Microsoft introduced "GDI scaling" (https://blogs.windows.com/windowsdeveloper/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/) for DPI-unaware applications where it is too much work or simply possible to make them DPI aware.

"GDI scaling" is also referred to as "enhanced system scaling" and can be activated in the application manifest or by reaching out to the properties dialog of the application file, see section "Configuring a local app to run with enhanced system scaling" in the blog article provided above.

While Toolkit Pro made progress to be DPI aware, there are lots of glitches when it is used with GDI scaling, especially when used with non-integral scale factors like 250%:


Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 865
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post Posted: 30 August 2022 at 11:19am
I tried this scaling and the results were pretty sad across the board. Microsoft indicated they knew this and were working on yet another approach via a "virtual DPI" system.

I'm not sure CJ can do much about making GDI scaling better.
Back to Top
mnissl View Drop Down
Groupie
Groupie


Joined: 12 June 2018
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote mnissl Quote  Post ReplyReply Direct Link To This Post Posted: 14 September 2022 at 4:15am
[QUOTE=rdhd]
I'm not sure CJ can do much about making GDI scaling better.
[/QUOTE

Of course they can: while a lot of things work out of the box with GDI scaling, some code needs to be adjusted. The very same procedure as with supporting true DPI awareness.

GDI scaling is crucial for MFC applications: there a lot of controls and applications out there which will never support HDPI. GDI scaling is a way to make most of them look acceptably good without touching the source code.

As Codejock made their controls DPI aware, they should also make them compatible with GDI scaling.
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 865
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post Posted: 16 September 2022 at 9:56am
When you build an MFC app, even with VS 2022, there is no choice for GDP+ scaling in the project setting's manifest property page.

When you set an app to be GDI DPI scaled, GetThreadDpiAwarenessContext returns a value which when passed to GetAwarenessFromDpiAwarenessContext will return DPI_AWARENESS_UNAWARE. That value is the same value you get it you set your awareness to "None" in the MFC project manifest setting.

Essentially, I have not seen any difference when asking the thread for its context between DPI_AWARENESS_CONTEXT_UNAWARE and DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED.

The only thing that is aware, is GDI itself from what I've ever been able to tell.

So, how do you determine programmatically what the awareness is?
Back to Top
mnissl View Drop Down
Groupie
Groupie


Joined: 12 June 2018
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote mnissl Quote  Post ReplyReply Direct Link To This Post Posted: 16 September 2022 at 1:09pm
Originally posted by rdhd rdhd wrote:

When you set an app to be GDI DPI scaled, GetThreadDpiAwarenessContext returns a value which when passed to GetAwarenessFromDpiAwarenessContext will return DPI_AWARENESS_UNAWARE.


Yes, the app is DPI-unaware: the app is not aware that it is being GDI scaled. Functions like GetWindowRect() return logical, not physcial coordinates.

But GetThreadDpiAwarenessContext() is your friend: it will tell you that the context is DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED.

This is how an app can detect that GDI scaling is performed:

const auto context = ::GetThreadDpiAwarenessContext();
ASSERT(::AreDpiAwarenessContextsEqual(DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED, context));

Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 865
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post Posted: 19 September 2022 at 3:21pm
I see that value and as I noted, I just pass it on to the other API. Again, what are you seeing you think needs to be improved by CJ?

I have made local improvements for some features like dragging docking panes across multiple monitors that have differing DPI scale factors. But, there is nothing I can do about MFC dialogs. Even Microsoft has closed cases I opened against MFC by essentially saying use a different awareness.

Example - just build a MFC old fashioned app with toolbars and don't use their default (which I think is per monitor). Then float a toolbar and try to drag it to another monitor. I have my main monitor set to my 4k scaled at 200%. I can't drag nor resize the MFC floating frame window that hosts the toolbar and get consistent results.

MS Inking also only works for per monitor aware (we use that subsystem in our app) and again, we were told, don't use a setting that doesn't work for MS code.

As I noted, MS told us they know about all the problems in their Apps. Spyxx, Visual Studio and others. Visual Studio find and replace will often show up as a tiny window until I click it. Other MS windows do the same. We were told "wait for the virtual DPI system" they are working on.

And don't even try using multiple monitors with various scaling and then connect from another box using remote desktop. When I get back to the office and sign in, I often find Outlook mail windows are humongous. I have to drag, resize, drag, resize ... until the mail window finally is not extended out to New Mexico.
Back to Top
mnissl View Drop Down
Groupie
Groupie


Joined: 12 June 2018
Status: Offline
Points: 12
Post Options Post Options   Thanks (0) Thanks(0)   Quote mnissl Quote  Post ReplyReply Direct Link To This Post Posted: 20 September 2022 at 10:23am
Originally posted by rdhd rdhd wrote:

I see that value and as I noted, I just pass it on to the other API.

There is no sense in passing it to the other API if you want to find out whether the application is GDI scaled.

Originally posted by rdhd rdhd wrote:

Again, what are you seeing you think needs to be improved by CJ?

The upper half of the screenshot in my original post represents the ribbon that is drawn by CodeJock, not Microsoft. And it shows several glitches:

  • The big blue rectangle on the left hand side which actually should be the application menu button (which is supposed to fill that white rectangle underneath the QAT).
  • When you mouse over ribbon buttons, the appear and remain blurred (middle section).
  • The "system menu" (minimize, maximize and close buttons) in the top right remains black after you hovered over it -- it should have a white backgorund again.
These are all issues CodeJock is supposed to solve, not Microsoft.
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 865
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post Posted: 23 September 2022 at 11:53am
Passing it on makes perfect sense to me as I don't care about GDI scaling as we simply don't use it. We use either per monitor aware or system aware. I have that code for debugging purposes only so I can track which of the two scaling modes I have enabled programmatically. And, whether a user has overridden that  mode via the advanced properties UI the OS provides for an executable.

When an issue does arise, I just fix them and post here on the forums regarding the same. So far, I have been able to do so without modifying CJ code directly when it comes to DPI scaling issues except in one case that I know of which was due to a 19.3 change related to CJ's use of their auto-scaling mode, which we don't use.

If you want a CJ fix, open a support case.
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.156 seconds.