Override non-standard font/text size in Windows 7

[Spiff59]

We started an office-wide conversion from Windows XP Pro SP3 to Windows 7 x64 SP1 a couple months ago.

About 1/3 of our 40 PC's have been updated and I've run into problems when people adjust their default text size.

If you right-click a blank area of the desktop, select "Personalize" then click on "Display", you're given options for text size.

The default shows as "Small - 100%", some of our users have switched it to "Medium - 125%".

This enlarges the fonts in my Autoit apps, but not the controls themselves (labels, buttons, etc).

The result is that a lot of the data shown on the GUI is truncated.

I found a thread where Guinness posted this function:

Func _GUICtrlSetTheme($iControl = -1)
     If Not IsHWnd($iControl) Then $iControl = GUICtrlGetHandle($iControl)
     Local $aReturn = DllCall("UxTheme.dll", "int", "SetWindowTheme", "hwnd", $iControl, "wstr", 0, "wstr", 0)
     If @error Then Return SetError(1, 1, 0)
     Return $aReturn[0]
EndFunc ;==>_GUICtrlSetTheme

Either I'm calling it incorrectly, it doesn't work, or the setting I'm trying to override is not considered part of the theme?

I just inserted the call (which returns @error = 0) like this:

$Main_GUI = GuiCreate($AppName & "               (" & @ComputerName & ")", 560, 440 + $ShowScan * 107, $PositionLeft, $PositionTop)
_GUICtrlSetTheme($Main_GUI)

Any ideas?

Thank you.

Edited April 8, 2013 by Spiff59

[KaFu]

Imho the problem is not the font size, but that the people changed the display DPI. Give something like this a try:

expandcollapse popup

Global $__i_SetFont_DPI_Ratio = _SetFont_GetDPI() ; for _SetFont_Ctrl() & _SetFont_hWnd()
$__i_SetFont_DPI_Ratio = $__i_SetFont_DPI_Ratio[2]

; Usage Examples only
GUISetFont($iSize / $__i_SetFont_DPI_Ratio, $iweight, $iattribute, $sfontname, $hWnd, $iquality)
GUICtrlSetFont($icontrolID, $iSize / $__i_SetFont_DPI_Ratio, $iweight, $iattribute, $sfontname, $iquality)


Func _SetFont_GetDPI()
    ;; Get the current DPI (dots per inch) setting, and the ratio between it and
    ;; approximately 96 DPI.
    ;;
    ;; Retrun a 1D array of dimension 3.  Indices zero is the dimension of the array
    ;; minus one.  Indices 1 = the current DPI (an integer).  Indices 2 is the ratio
    ;; should be applied to all GUI dimensions to make the GUI automatically adjust
    ;; to suit the various DPI settings.
    ;;
    ;; Author: Phillip123Adams
    ;; Posted: August, 17, 2005, originally developed 6/04/2004,
    ;; AutoIT 3.1.1.67 (but earlier v3.1.1 versions with DLLCall should work).
    ;;
    ;; Note: The dll calls are based upon code from the AutoIt3 forum from a post
    ;; by this-is-me on Nov 23 2004, 10:29 AM under topic "@Larry, Help!"  Thanks
    ;; to this-is-me and Larry.  Prior to that, I was obtaining the current DPI
    ;; from the Registry:
    ;;    $iDPI = RegRead("HKCU\Control Panel\Desktop\WindowMetrics", "AppliedDPI")
    ;;

    Local $a1[3]
    Local $iDPI, $iDPIRat, $Logpixelsy = 90, $hWnd = 0
    Local $hDC = DllCall("user32.dll", "long", "GetDC", "long", $hWnd)
    Local $aRet = DllCall("gdi32.dll", "long", "GetDeviceCaps", "long", $hDC[0], "long", $Logpixelsy)
    Local $hDC = DllCall("user32.dll", "long", "ReleaseDC", "long", $hWnd, "long", $hDC)
    $iDPI = $aRet[0]
    ;; Set a ratio for the GUI dimensions based upon the current DPI value.
    Select
        Case $iDPI = 0
            $iDPI = 96
            $iDPIRat = 94
        Case $iDPI < 84
            $iDPIRat = $iDPI / 105
        Case $iDPI < 121
            $iDPIRat = $iDPI / 96
        Case $iDPI < 145
            $iDPIRat = $iDPI / 95
        Case Else
            $iDPIRat = $iDPI / 94
    EndSelect
    $a1[0] = 2
    $a1[1] = $iDPI
    $a1[2] = $iDPIRat
    ;; Return the array
    Return $a1
EndFunc   ;==>_SetFont_GetDPI

Edited April 8, 2013 by KaFu

[Spiff59]

You nailed it.

It's the DPI setting, and that's not a part of the theme.

Being a setting that affects the entire monitor/display it looks like the solution you provide is the way to go.

The program is 2600 lines with a cram-packed GUI and 3 or 4 child GUI's. There are likes dozens of font statements. I think it might be easier for me to do a global replace changing GUISetFont() and GUICtrlSetFont() to GUISetFont_DPI() and GUICtrlSetFont_DPI(), then create the DPI functions that apply the ratio returned by _SetFont_GetDPI() and then call the standard built-ins.

Thank you, KaFu

Edited April 9, 2013 by Spiff59

[KaFu]

Glad it worked out for you .

[Kilmatead]

I think it might be easier for me to do a global replace changing GUISetFont() and GUICtrlSetFont() to GUISetFont_DPI() and GUICtrlSetFont_DPI()...

As a coder "of a certain age" who uses higher DPI (as is downright necessary on higher-res LCD's), I feel the need to point out that the ratio returned by Phillip123Adams' original function does not necessarily have to be used in a reductionist fashion. By concentrating on reducing the font sizes (effectively punishing the users who, perhaps with good reason, changed their settings) you're forcing them to adapt to Lilliputian standards.

Thus, the same ratio may be applied instead to the creation of the controls themselves (leaving the font sizes alone), which simply results in the "expected" behaviour of an application under higher-DPI - de facto "inflating" the GUI, which keeps everyone happy.

Basically, this amounts to multiplying everything by the ratio (and I mean everything) - for example...

#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>

Global Const $DPI = _GetDPI() ; Phillip123Adams simplified to only return the ratio

_Main()

Func _Main()
    Local $lWidth = 300, $lHeight = 150
    Local $Form = GUICreate("DPI Test", $lWidth * $DPI, $lHeight * $DPI, -1, -1)
    GUISetFont(9, 400, 0, "Segoe UI") ; The '9pt' size is merely reference constant - the true size is determined by the Window's environment itself

    GUICtrlCreateLabel("Miss not, Dear Coder, the Forest for the Trees...", (($lWidth / 2) - 125) * $DPI, 53 * $DPI, 250 * $DPI, 18 * $DPI, BitOR($SS_CENTER, $SS_SUNKEN))
    Local $Button_OK = GUICtrlCreateButton("Ok", ($lWidth - 185) * $DPI, ($lHeight - 40) * $DPI, 75 * $DPI, 25 * $DPI)
    Local $Button_Cancel = GUICtrlCreateButton("Cancel", ($lWidth - 95) * $DPI, ($lHeight - 40) * $DPI, 75 * $DPI, 25 * $DPI)

    GUISetState(@SW_SHOW, $Form)

    While True
        Switch GUIGetMsg()
            Case $Button_OK
                ContinueCase
            Case $Button_Cancel, $GUI_EVENT_CLOSE
                ExitLoop
        EndSwitch
    WEnd

    GUIDelete($Form)
EndFunc

Now, I'm the first to admit that supporting this paradigm requires more effort to maintain (almost too much effort, if you attempt to retrofit an already mature project) - so it's best used when starting new projects which are meant to be at play in the wild, where many users will have many setups which you can't control or predict.

The long-term benefit being, of course, that all users are happy - those who use normal DPI simply have a lot of superfluous multiplcation-by-1 processing - but take the same code and apply it to a user with DPI of 1.25 and the benefits become clear (at least to those with eyes not quite as strong as their stubborn resolves).

In the above example I intentionally made the definitions more complex than merely using constants just to show how messy it can get - but it's worth it in the long run. Note that occasionally you can run into circumstances where the result of sending a floating-point (the result of ratio multiplication) to a control can lead to some things being "off" by a pixel or two... which is why I usually define a couple of offset constants just for fun (to add or subtract as needed)...

Global Const $Offset = Int($DPI = 1), $cOffset = BitXOR($Offset, 1) ; Offset/Counter-Offset for DPI pixel irregularities

...for instance, sometimes a DPI-aware single-pixel counter-offset needs to be applied after the initial DPI scaling computation, as in:

(16 * $DPI) - $cOffset

...but that's merely semantics. Anyway, this is just a suggestion - most high-DPI users find it offensive when lazy coders neglect this side of GUI design and assume that everyone likes to live in the same boring cookie-cutter world as they do. Subtle attention to detail like this will win you more users in the long run, than would efforts spent on less-functional ephemera like fancy toolbars and fluff.

[Spiff59]

One of my first thoughts was that the correct way to do this would be to expand everything else to match the requested font size.
The very next thought was "That's a lot of work!"

So far, I know of only 2 users running at 125% DPI, and the affected program will become obsolete when we complete our slow transition to our new EMR system (another year or two).
I'm considering it a compromise, just patching the 2 font statements, they can keep their DPI setting, and I can sooner return to projects which promise to yield better benefits to end-users.

Edit: This does leave hanging the question about what to do in future development regarding DPI. Apparently, other applications do apply DPI to all controls and not just fonts as none of our commercial apps have gone haywire? I wonder how they do it, and what we're lacking...

I ended up just doing a global replace on the GUISetFont() function name, and then inserting the following near the top of the program:

Global $iDPI_Ratio = _GetDPI_Ratio()

And this near the bottom:

Func GUISetFont_DPI($isize, $iweight = "", $iattribute = "", $sfontname = "")
    GUISetFont($isize / $iDPI_Ratio, $iweight, $iattribute, $sfontname)
EndFunc

Func GetDPI_Ratio()
    Local $hWnd = 0
    Local $hDC = DllCall("user32.dll", "long", "GetDC", "long", $hWnd)
    Local $aRet = DllCall("gdi32.dll", "long", "GetDeviceCaps", "long", $hDC[0], "long", 90)
    $hDC = DllCall("user32.dll", "long", "ReleaseDC", "long", $hWnd, "long", $hDC)
    If $aRet[0] = 0 Then $aRet[0] = 96
    Return $aRet[0] / 96
EndFunc

Edited October 9, 2013 by Spiff59