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.

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

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:

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.

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:

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?

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

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.