MFC with GDI+ DPI aware

[hundsmiachn]

Hi

I want to make an MFC app which displays controls on the left and a bitmap with some graphics on the right.
My problem is now, how do I have to draw the graphic elements (gdiplus rectangle , line, circle) so that they are always on the same position in relation to the windows controls? I draw the controls in Visual Studio 2019 with the resource editor, the graphic elements are drawn by code.
(DPI is set to HIGH in the mfc project settings).

I have drawn two red rectangles, one with the size of the dialog and an inner one which is the size of a group box. For the size of the dialog rectangle I use GetClientRect. It works on all font sizes (DPI scalings) correct.
For the inner rectangle inside the group box I tried to recalculate the coords with GetDeviceCaps, but that does not work. If I change scaling in windows the inner rectangle is completely off.
So I tried to figure out the correct coords for the inner rectangle by trial and error. Below are the coords which draw the correct rectangles in relation the the group box.
But how can I calculate them, I get some weird values? In the x axis I would get a factor of 1.3328 and on the y axis a factor of 1.62 with 150% scaling????

http://public.stattegg.info/_old/dpiproblem.jpg

// coords at 100%
Dialog rectangle coord = 0/0 - 1445/832
group box rectangle coord = 624/9 - 1247/581

// coords at 125%
Dialog rectangle coord = 0/0 - 1685/1088
group box rectangle coord = 728/11 - 1456/761

// coords at 150%
Dialog rectangle coord = 0/0 - 1926/1344
group box rectangle coord = 831/13 - 1664/941

How can I calculate the right coordinates for this elements ?

thanks
regards
Erich

[deleted account xyzzy]

https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows

MFC (and Win32) use has pretty much been deprecated, Universal Windows Platform (UWP) is what MS recommends now for new apps. Apps automatically re-scale the UI when DPI changes.

ETA: I know this doesn't really address your issue, but trying to find information that isn't years old and no longer updated is hard. Accurate information using MFC is even more difficult.

[eugenedakin]

Hello hundsmiachn,

After doing lots of work on this in 2016, HiDPI does rezise correctly, albeit it takes some work to get used to. I don't have a HiDPI screen, since I have not seen many programs use this algorithm much in the last 4-years.

In general, the x-scale and y-scale can be different when the screen ratio's are also changing for a program having a form maximized.

For example, going from a screen with a resolution from 1920 x 1080 (1.77 ratio) to 3000 x 2000 (1.5 ratio) will change the appearance of the form when the form is not maximized and the form and controls will look correct. When the form is maximized, one ratio (lets say the x-scale) will be at one value and the y-scale will need to be scaled to the y-axis which will change the x-scale and y-scale for HiDPI. This will make the controls appear weirdly stretched in one direction.

Furry Guy is correct that Universal Windows Platform (UWP) mostly calculates all of this for you. You will need to calculate these screen dimensions manually in Win32 and then resize the form and controls accordingly on your screen so that they look acceptable to the user.

Another aspect is that HiDPI drawings are using points instead of pixels. Physical hardware is measuring drawings in pixels on a screen, and HiDPI uses points since the physical size of the drawn object, like a line, will be different on all screens.