Extended Message Box - DPI Scaling

[Shark007]

I am at your service, bring it.

[Shark007]

I found it necessary to remove the scaling on line 561 - I still have minor issues with message width.

Local $hMsgGUI = GUICreate($sTitle, $iDialog_Width, $iMsg_Height, $iHpos, $iVPos, BitOR(0x80880000, 0x00C00000), $iExtStyle, $iParent_Win)

I also had some positioning issues with your setup but since I use ini files to track location, I completely removed your screen positioning to substitute my own.
I'll look at that again as time permits.

[Melba23]

Shark007,

I do not understand how scaling  cannot be required when creating the main dialog. If all the internal controls are scaled, surely the GUI in which they are positioned must also be scaled or it will be to small to hold them.

M23

[Shark007]

The gui is just too large. To me, it looks like the scaling is getting applied twice for the main GUI.

The width issue: The message gui looks fine @ 100% scaling but @ 225% it becomes too skinny.

I'll follow up with some Pics soon. Morning coffee isn't even ready yet.

[Shark007]

Using your latest posting of ExtMsgBox_DPI.au3 and the following context in my App (my app is aprox 500x300 for reference)

Screen positioning is handled by ExtMsgBox_DPI and all of the following pics were positioned by ExtMsgBox_DPI

_ExtMsgBoxSet(0, 0, $Contrast)
_ExtMsgBoxDPIScale($iScale)
_ExtMsgBox(0, 0, 'Instruction', "This button will created 2 WMP shortcuts in the Open With list." & _
        "The lower one is always the 64bit player. ALWAYS select to choose another app and also check the box to Always use," & _
        " then select your prefered player. After doing all filetypes with permission errors," & _
        "Select the appropriate player to use in the App", 0, $SetApp, 0, False)

@225% scaling, I see the following

And @100% i see this

When I remove the scaling as I pointed out earlier, @225 I see this

And @100% it is identical to my previous graphic @100 which does look OK.

Edited May 9, 2021 by Shark007

[Shark007]

I'm going to continue my experimentation and keep an eye here to see if you post anything new to try.

[Melba23]

Shark007,

Using your code I can see some size anomalies too. The dialog size is set by using my StringSize UDF to measure the space needed to display the content - I am wondering if that UDF also needs some tweaking to cope with the DPI scaling.

I did say this was likely to get messy!

M23

[Shark007]

14 minutes ago, Melba23 said:

Using your code I can see some size anomalies too. The dialog size is set by using my StringSize UDF to measure the space needed to display the content - I am wondering if that UDF also needs some tweaking to cope with the DPI scaling.

I did say this was likely to get messy!

M23

Yes, I have come to this same conclusion about StringSize also and was hoping you could get me started with something and I could tweak.
I had a look at it but I'm hoping you could point me in the right direction to get started.

[Melba23]

Shark007,

The problem is definitely the return from the call to StringSize. In my tests the label is sized at 350x79 when at 100% - while at 175% it returns 350x274.

I will continue looking into the problem as time allows.

M23

[Shark007]

I have made good progress tweaking the positioning in relation to a parent gui. (completed)

The StringSize issue is also affecting the message body as it is missing the [OK] button @ any DPI other than 100%

 

I am in no hurry for results. I am testing this with a function that I intend to deprecate
and my initial reason for looking at this has been resolved using SplashTextOn.

[Melba23]

Shark007,

It seems that you need to factor the text size passed to StringSize - or to be correct to the GetTextExtentPoint32W API call within the UDF - to get a sensible result. Strangely it seems you need to divide by the DPI scaling factor rather then multiply like everywhere else - perhaps because (as you pointed out) Windows automatically scales the font itself. Anyway, the results are much better, but still not perfect so I will continue to work on the issue.

M23

[Shark007]

I like that you mentioned 'division because I also am getting better results with the following

Local $hMsgGUI = GUICreate($sTitle, $iDialog_Width * $iDPI, $iMsg_Height / $iDPI + 25 * $iDPI, $iHpos, $iVPos, BitOR(0x80880000, 0x00C00000), $iExtStyle, $iParent_Win)

I'm not even sure why I did that ...   lol  (i'm old, and forgetful)

Edited May 9, 2021 by Shark007

[Melba23]

Shark007,

Try this for size: ExtMsgBox_DPI.au3

M23

[Shark007]

Wholly Crap!  That worked right out of the box.

I tested @ 225% (4-4 message) and 100% (9-9 message) , both were perfect.

[Shark007]

Have a look at the bottom row of text.

[Shark007]

That text anomaly at the bottom is @ 225%

 It is not occuring @ 100%

[Melba23]

Shark007,

I noticed that too and tried to get round it with code like this:

; DPI Aware code
Local $iDPI = $g_aEMB_Settings[14]
Local $iDPIFontSize = Ceiling($g_aEMB_Settings[4] / $iDPI)
Local $iDPIDefFontSize = Ceiling($g_aEMB_Settings[10] / $iDPI)

so that the font was always a trifle on the large side. It seemed to work for me at 175% but the problem obviously still exists at your extreme 225% scaling. You could try adding a bit to the font value and see if that gives a better result:

; DPI Aware code
Local $iDPI = $g_aEMB_Settings[14]
Local $iDPI_Factor = ($iDPI - 1) / 2
Local $iDPIFontSize = Ceiling(($g_aEMB_Settings[4] + $iDPI_Factor) / $iDPI)
Local $iDPIDefFontSize = Ceiling(($g_aEMB_Settings[10] + $iDPI_Factor) / $iDPI)

That way we are scaling the increase to the scaling factor rather than  adding the same amount regardless. And the factoring expression might need a bit of juggling - I leave that to you.

M23

[Shark007]

To my eyes, It seems the entire block of text has shifted downwards and getting impacted by the button space.

Is it possible to shift that entire block upwards 5 pixels?

[Melba23]

Shark007,

Quote

To my eyes, It seems the entire block of text has shifted downwards

That is not the problem - it is the reduced results from the  StringSize call making the whole label too small for the text at high scaling settings. That is why the text no longer fits and appears cut off. Adding 5 pixels to the label height would be a pure "fudge factor" to get over this and would affect label size at all scalings.  I prefer to look for a programmatic solution if possible.

M23

Edited May 9, 2021 by Melba23
Added a bit

[Shark007]

I'm currently working with the code you presented.  back soon