"GuiCtrls_HiDpi" (UDF in progress)

[argumentum]

... lets do some marketing first:



pardon the image size of 225% scale on another monitor

The idea is to have some DPI awareness in our GUIs and with this all you have to do is prefix "_HiDpi_" to your current code. Simple.

This version ( HiDpi v. 0.2023.7.29(b) stable.zip ) is stable but only system aware. ( pictures above )

---

This next version ( HiDpi v. 0.2023.8.3(a) under development.zip )  is what I've got so far in regards of per-monitor awareness

This one ( HiDpi v. 0.2023.8.4(ResizeTestbed) under development.zip ) is for the brave of heart. I'm looking for ideas. This is a testbed for anyone wanting to contribute regarding resizing controls.

I have now started to use _WinAPI_DPI.au3 because I feel that this UDF is ready for that UDF.
Therefore, too many and too big files for copy and paste. And that is good. Means that the UDF is getting closer to stable.

---

FAQ (of sorts)

Q: When did you come up with this ?
A: Never. These are helper functions for _WinAPI_SetDPIAwareness.au3 but I did not get to finish. Nonetheless it's functional as is and applies to most of the cases in need of DPI awareness. Per-monitor would need more involved coding and I only have so much time and know how for now.

Q: Will you open a ticket and ask to be included in the standard UDFs ?
A: No. This is a just for now. Eventually the functionality would be a standard feature without the need of this.

Q: Will you add ...
A: Only in the case that either, I realize is needed and code it or, you code it and ask to be included in this bundle of functions UDF

Q: This is not working ...
A: The best way to go about a problem with this code is to open it's own thread in GUI Help and Support and post there with a mention of me. I'll read and answer there.

Q: Are you going to share "logo4.gif", "SampleAVI.avi", etc.
A: You are right. I forgot to say that the example file will work as expected if created in "..\Examples\GUI\HiDpi_v_n.n.n.n\", as a subfolder of where "SampleControls.au3" is at. There it will find all the files required for the example. Because after all, this example is that example but "_HiDpi_fied" ( so to say ).

Q: Is there a tool that will magically update all my old scripts ?
A: I've posted a script to get you closer but is not magical. Should work just fine for simple GUIs.

Q: Are you going to work on a Per-monitor version ?
A: yes, as time permits.

---

Edited February 13, 2024 by argumentum
..if dyslexia/ADD/ADHD are reasons for edit then yes.

[UEZ]

Hi @argumentum,

I will test your script on Monday in the office where I have 3 monitors and can set different DPI settings per monitor.

Edited July 28, 2023 by UEZ

[argumentum]

...this approach is simple and should work flawlessly if, all monitors have the same scaling. Otherwise will take the scaling of the monitor declared as primary, and adjust in a blurry way the difference.
As a first step, should work for most people as they have only one monitor.
Those with more than one, if bought together then is also functional.

Now, those like me that have, in my case say, a 21:9 1080p next to a 16:10 4k, it looks perfect only for the primary but again, most people don't have such setup.
Hence an incentive for me to have a full "PER_MONITOR_AWARE_V2" instead of the "SYSTEM_AWARE" that I posted.

[argumentum]

Updated the example on the first post to show the need for _HiDpi_WinGetPos().

[mLipok]

  On 7/29/2023 at 5:24 AM, argumentum said:

_HiDpi_WinGetPos().

Expand  

can you provide the same for _HiDpi_ControlGetPos()

I mean there are many problems with clicking into Controls because of HiDpi, and some recalculation of control positions are needed before click point will be properly given.

Edited July 29, 2023 by mLipok

[mLipok]

  On 7/29/2023 at 4:14 AM, argumentum said:

Now, those like me that have, in my case say, a 21:9 1080p next to a 16:10 4k, it looks perfect only for the primary but again, most people don't have such setup.

Expand  

I have.

[mLipok]

I indicate this UDF as a candidate for:
https://www.autoitscript.com/wiki/User_Defined_Functions

[argumentum]

  On 7/29/2023 at 8:54 AM, mLipok said:

can you provide the same for _HiDpi_ControlGetPos()

Expand  

Yes, added. And thanks for the idea. This UDF will build itself as ideas come to mind. In this case I did not think of ControlGetPos() because it did not cross my mind but thanks to sharing in a forum, we all pitch in

[argumentum]

What's new with version  0.2023.7.30(a)

A first try at a per-monitor awareness. There is an array to keep tabs on what's going on BUT no maintenance yet. Nor proper font keeping. I don't even know how I'm planning to do what yet.
I'm using $GUI_DOCKAUTO to keep controls in place but have to come up with something better. Don't know yet. Weekend is over and I'm out of time for now.

Any ideas in the form of code example always welcomed

Oh, the original file is there for download and so is this one, for those that rather get the files than copy'n'paste.

[UEZ]

In my office I have 3 monitors horizontally next to each other. The DPI for this: 100%, 125% and 150%. The main screen is in the middle (125%).

 

HiDpi v. 0.2023.7.29(a) stable looks ok.

 

The dev. version HiDpi v. 0.2023.7.30(a):

 

Edited July 31, 2023 by UEZ

[argumentum]

_HiDpi_fier("OwnTab.au3") ; set the filename of the script to HiDpiFY
Func _HiDpi_fier($sFilenameFullpath)
    Local $aFile = FileReadToArray("GuiCtrls_HiDpi.au3") ; also, this one would be where you have it at
    Local $iToPrefix = 0, $aToPrefix[UBound($aFile)][5] = [[0]]
    For $n = 0 To UBound($aFile) -1
        If StringLeft($aFile[$n], 15) <> "Func _HiDpi_GUI" Then ContinueLoop
        $iToPrefix += 1
        $aToPrefix[0][0] = $iToPrefix
        $aToPrefix[$iToPrefix][0] = $aFile[$n]
        $aToPrefix[$iToPrefix][0] = StringTrimLeft($aToPrefix[$iToPrefix][0], 5)
        $aToPrefix[$iToPrefix][0] = StringLeft($aToPrefix[$iToPrefix][0], StringInStr($aToPrefix[$iToPrefix][0], "("))
        $aToPrefix[$iToPrefix][1] =  StringTrimLeft($aToPrefix[$iToPrefix][0], 7)
    Next
    ReDim $aToPrefix[$iToPrefix + 1][5]
    Local $sScriptToIfy = FileRead($sFilenameFullpath)
    If Not StringLen($sScriptToIfy) Then Return MsgBox(0, @ScriptName, "could not load:" & @LF & $sFilenameFullpath, 10)
    If StringInStr($sScriptToIfy, "_HiDpi_GUI") Then Return MsgBox(0, @ScriptName, "Already done ?", 10)
    For $n = 1 To $aToPrefix[0][0]
        $sScriptToIfy = StringReplace($sScriptToIfy, $aToPrefix[$n][1], $aToPrefix[$n][0])
        $aToPrefix[$n][2] = @extended
        If $aToPrefix[$n][2] Then ConsoleWrite('- "' & $aToPrefix[$n][1] & ')"''s replaced: ' & $aToPrefix[$n][2] & @CRLF)
    Next
    $sScriptToIfy = '#include "GuiCtrls_HiDpi.au3"' & @CRLF & '_HiDpi_Ctrl_LazyInit() ; move this to, ..where it makes sense.' & @CRLF & @CRLF & $sScriptToIfy
    ConsoleWrite($sScriptToIfy & @CRLF)
    ClipPut($sScriptToIfy) ; ..ready to paste back after you made a backup of the original  ;-)
    ; You may also need to add a "_HiDpi_CtrlAdjRatio( $iYourPixleValue, 1)" here and there. 
    ; This script is just to get you closer and not have to edit everything by hand.
EndFunc

..I say "..just prefix _HiDpi_ and you're good.." but in truth, is hard to visually replace stuff so, the above is meant to get you closer. 

Edited August 1, 2023 by argumentum
better code

[argumentum]

What's new with version  0.2023.8.1(a)

..think I've got the font size right. Next is ... more font stuff. After, maintenance stuff.

[Shark007]

using version  0.2023.8.1(a) 

The 1st Pic is a direct compie of the script supplied and the 2nd pic is using the manifest mod we spoke of in the other thread

[argumentum]

thanks for the post @Shark007. This is bewildering to me. The code itself should do away with a manifest as is making the call after the loading of the code, by which whatever was set as manifest should not matter, I say ( DllCall and what not ) to set DPI per process to such, or such.

In any case, the manifest works well with the code as is in the example if the manifest aligns with it. Could you compile it removing the line that say "LazyInit" ?. That would be helpful. If it looks worse than the 2nd pic, I've got it, otherwise, I'll ask for your OS, monitors, monitor arrangement and settings and other hardware, and maiden name.  

[argumentum]

..all good. Got it. x32 don't matter but x64 needs the manifest.

[argumentum]

changed the example ( the copy'n'paste one ) to be able to show some pertinent info. :

[Shark007]

The 1st pic is a direct compile of the code provided. ( 0.2023.8.1(d) ) The 2nd pic uses the manifest to enable DPI

also take notice specifically ... the Sample Button text.

 

Edited August 2, 2023 by Shark007

[argumentum]

Thanks @Shark007. I found that under x64 the manifest is a must.
Hence the reason to run the non-compiled script as x32 given that AutoIt3.exe does not have the "dpiAware" part on it's manifest.

[Shark007]

  On 8/2/2023 at 11:37 AM, argumentum said:

I found that under x64 the manifest is a must.

Expand  

x64 compile is an absolute MUST HAVE to avoid false positives.

[argumentum]

What's new with version  0.2023.8.2(a)

Font size is good. Array of controls has maintenance. Started to use _WinAPI_DPI.au3. So far so good.