Hmm... I'm realising a few issues about this... Please hear me out.
First off, I can't test DPI-Awareness very effectively AT ALL. I only have one monitor, so I can't test for multi-monitor situations. Also my debug program (or ANY of the programs and extensions I have been running, including actual Windows apps, professional 3rd-party apps, and extensions, both professional and nonprofessional) did NOT respond to dynamic DPI changes. Settings actually says: "Some apps won't respond to scaling changes until you sign out." In fact, the ONLY app that DID respond to dynamic changes was the settings app. Everything else did not dynamically respond to changes. But when I signed out and re-opened my apps and stuff, EVERYTHING was fine, no blurry fonts or controls. EVEN the debug program was fine (I have created a manifest with the aid of the MSDN which hopefully enabled high-dpi awareness, which I tested and it does seem to work, see below).
This all tells me that, if it is
important, absolutely
critical for applications to respond to DPI-changes
dynamically, then the apps I had been running WILL have responded, but they DID NOT.
Also, if you were to change your DPI setting, you'd probably
have to close everything down and restart anyway? I mean, it's not like people are constantly changing the DPI all the time: they would set it once to the scaling they needed, and
leave it alone.
Which leads me to say that this is something I cannot incorporate into the OGL, simply because I
can't. Let me explain:
The page
here tells of four basic steps:
MSDN wrote:Supporting Dynamic DPI Changes
You must perform the following steps to make your application per monitor-DPI aware:
1. Set the DPI awareness level
2. Get the DPI for the current monitor
3. Listen for DPI changes
4. Respond to changes
1. Setting DPI awareness.This is best done through the manifest file of an application. Setting it through a function has disadvantages (?). Therefore, this is something that cannot be part of the OGL simply because you can't put a manifest file into the OGL.
2. Getting DPI for current monitor.I am incorporating this functionality through the following functions (there is also a function to retrieve the monitor handle of primary, secondary monitor etc.):
Code: Select all
'monitor is a function which retrieves a monitor's handle. The default is the primary monitor
function monitordpix(byval m as HMONITOR = monitor) as ulong
dim as ulong mx, my
dim as any ptr dll = dylibload("shcore.dll")
if dll <> NULL then
dim dpi as function (as HMONITOR, as uinteger, as UINT ptr, as UINT ptr) as HRESULT
dpi = dylibsymbol(dll, "GetDpiForMonitor")
if dpi <> NULL then dpi(m, 0, @mx, @my) 'effective dpi
dylibfree(dll)
endif
return mx
end function
function monitordpiy(byval m as HMONITOR = monitor) as ulong
dim as ulong mx, my
dim as any ptr dll = dylibload("shcore.dll")
if dll <> NULL then
dim dpi as function (as HMONITOR, as uinteger, as UINT ptr, as UINT ptr) as HRESULT
dpi = dylibsymbol(dll, "GetDpiForMonitor")
if dpi <> NULL then dpi(m, 0, @mx, @my) 'effective dpi
dylibfree(dll)
endif
return my
end functionNow I get it: in order to dynamically respond to DPI changes, one must use WM_DPICHANGED, or do they? Does that message only respond if a window has been moved to another monitor with another DPI setting? Well, screw that, since I don't have two monitors to test with (or could any of you guys help me out with this?).
How does one listen for dynamic changing of the DPI
setting? If I had this knowledge, then I could think about responding to dynamic changes of the DPI setting. But as it stands now, it appears that... I don't know how to do it...
4. Respond to changes.Then I just thought...
Do I have to add scaling methods?
I mean, I've taken a look at CWindow.inc. As far as I'm aware, all the scaling properties are doing is multiplying the x and y coordinates of a control by a specified value. Do I have to add special methods for this, or can the programmer just do it himself/herself? Not to demine José Roca or his work or anything of the sort. It's great! Just that I personally do not see the need to incorporate this:
when the programmer can simply create their own section or procedure dealing with this issue.
I will still be adding things like monitor handle, dimension, and dpi retrieval.
As for images and fonts, the programmer can easily change the logical widths and heights of the fonts and use separate images for each scaling setting. The OGL itself cannot do this easily, especially the images problem, since the OGL does not know what stored image is the scaled one you want for a particular DPI setting, does it? And if I somehow incorporate this logic into the OGL, it will make things more complex than it needs to be! Well, definitely more complex than this:
Code: Select all
win.image(ci) = imgindex
'imgindex is index of image which corresponds with the scaled version of the original imageSomething else to consider is that some programmers may want to have more control over scaling. Then, writing a scaling method or methods may not be helpful to them.
===============================
In order to incorporate High-DPI awareness into your program, you have to write the correct manifest.
That is it. If someone were to change the DPI setting dynamically, then they just
have to sign out and back in again, there's nothing much I can do about that.
In other words, if you write the real manifest, you've done it. In order for the program to respond to the changes, you have to sign out and in.
Now, OGL didn't do any of that, did it?... It was the manifest.
This is why I am saying I can't exactly incorporate this feature into the OGL. I can certainly help by providing DPI retrieval functions etc., but to actually handle dynamic changes, the programmer has to do it from scratch.
Overall, while I appreciate the need for DPI-awareness, creating methods to perform a few multiplication sums is a bit, meh... Idk...
