"GuiCtrls_HiDpi" (UDF in progress)

[Shark007]

@UEZ The Latest UDF is working good for me without any modification except for one line which all are predefined in WinAPIsysinfoConstants.au3

So I commented the line

Global Const $SPI_GETICONTITLELOGFONT = 0x001F, $SPI_GETICONMETRICS = 0x002D, $SPI_GETNONCLIENTMETRICS = 0x0029

And I have working and functional UDF.

[Shark007]

@argumentum I just tested using the latest iteration of GuiCtrls_HiDpi.au3 and have nothing anomolous to report.

[argumentum]

I should not spend time on this as I need to attend to my work. I should have been a painter. Then again, when you paint for a living you find your self's inspiration cut short due to clients demands. I should be a child, and with enough time I'm told I'm likely to go back to have those early childhood events reoccur. But I'm going off topic.

If the user has monitors in X multipliers its a good setup for GUIs, say 100% here and 200% there. But if you have 225% there, then your code leaves you with a decimal.
Having a decimal forces to either round, floor or ceiling the number. I left it to AutoIt to decide by changing the resizing/anchoring and going back and forth, and on that condition, it does not look good. There are no partial pixels.

Debugging for me is to expose the code to any environment that would be unexpected and actively abuse it until it brakes.
Since this UDF would be used in odd circumstances, it should be coded to behave on those conditions too. I even attend to conditions a newbie would mess up and not have the function brake the script in say, it should return an array and on @error, it still returns an array, as an array is expected because most newbies here don't check for the error flag and it would crash their code. I may even be offered a Nobel Price, given my contributions to humanity. But I'm going off topic.

It works but no cigar. The last thing we need in this community is to offer something with a promise, but didn't take this or that into consideration. 100 caveats.
Then the AutoIt sucks because it does not work, even though it was the UDF.

Anyone testing this, please do try to brake it. And if you successfully broke it, fix it. ( and share the code for the rest of us copy'n'paste kind of people. ) 

Edited August 5, 2023 by argumentum
spelling

[simplercoder000]

I have tried compiling the version: HiDpi v. 0.2023.7.29(a)

but I'm running into this error:

Return $aResult[0]
Return $aResult^ ERROR

 

I'm running on Windows 7 x64

[argumentum]

42 minutes ago, simplercoder000 said:

but I'm running into this error:

Never tried in Win7. The error comes from _HiDpi_GetDpiForWindow() that in itself is adaptation from https://www.autoitscript.com/forum/topic/139260-autoit-snippets/?do=findComment&comment=1521526 .

Replace this and let me know.

;https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdpiforwindow
Func _HiDpi_GetDpiForWindow($hWnd = Default)
    Local $iErr, $iExt, $aResult, $gui = 0
    If $hWnd = Default Then $gui = GUICreate("")
    Local $aResult = DllCall("user32.dll", "uint", "GetDpiForWindow", "hwnd", ($gui ? $gui : $hWnd)) ;requires Win10 v1607+ / no server support
    $iErr = @error ; adaptation from https://www.autoitscript.com/forum/topic/139260-autoit-snippets/?do=findComment&comment=1521526
    $iExt = @extended ; were the original code can be found.
    If $gui Then GUIDelete($gui)
    If $iErr Or Not IsArray($aResult) Then Return SetError($iErr + Int($iErr ? 0 : 100), $iExt, 96)
    Return $aResult[0] ; should be retutning an array[2] 
EndFunc   ;==>_HiDpi_GetDpiForWindow

..an oversight of my copy and paste. I should have used If $iErr ... .

Edited February 13 by argumentum
better code ?

[simplercoder000]

6 minutes ago, argumentum said:

Replace this and let me know.

This time the example has compiled without any errors but the DPI issue are still there :(

[argumentum]

3 minutes ago, simplercoder000 said:

but the DPI issue are still there

I don't have a Win 7 to have a go at it
The error was fortunately easy to correct but to see on a screen, I'll need to have a Win 7 to look at. It'll take me a few days to investigate. Then again, if  _HiDpi_GetDpiForWindow() failed it means that the OS does not recognize it.

@UEZ, help 

 

[argumentum]

tho in the function notes it has as reference https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdpiforwindow

It say on the bottom of the screen:
Minimum supported clientWindows 10, version 1607 [desktop apps only]
Minimum supported serverWindows Server 2016 [desktop apps only]

[argumentum]

Updated the ZIP on the 1st post with the fix for _HiDpi_GetDpiForWindow().

[simplercoder000]

8 minutes ago, argumentum said:

tho in the function notes it has as reference https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getdpiforwindow

It say on the bottom of the screen:
Minimum supported clientWindows 10, version 1607 [desktop apps only]
Minimum supported serverWindows Server 2016 [desktop apps only]

Searching in the forum again I back to this thread here:

Adding this line into the example script seems to enable the High DPI mode:

DllCall("User32.dll", "bool", "SetProcessDPIAware")

I just added somewhere before the GUI loads

 

Now the example has become DPI awareness but the GUI is unsorted well !

[argumentum]

1 minute ago, simplercoder000 said:

Adding this line into the example script seems to enable the High DPI mode

...yes, it's a pickle. This UDF am putting together is just helper functions for the rest of the code that I scrapped off the forum.
Its "GuiCtrls_HiDpi" (UDF in progress). Unfortunately, right now, I'm really busy with work. I'll have a deep look at it as soon as I can install Win7 and give it full attention.

Do pardon. I thought that the stable version was sufficiently functional.

[argumentum]

13 minutes ago, simplercoder000 said:

but the GUI is unsorted well !

for now, play with

EndFunc   ;==>_HiDpi_GUICreate <<<< righ after this line add
GUISetFont(4)  ; add this. Change the font to something functional ?

 

[argumentum]

nope, it's not going to fix Menu or TAB. But if you don't use those in you GUI, maybe is good enough. Let me know.

[simplercoder000]

1 hour ago, argumentum said:

for now, play with

EndFunc   ;==>_HiDpi_GUICreate <<<< righ after this line add
GUISetFont(4)  ; add this. Change the font to something functional ?

 

I have tried this but it's didn't changes anything in the GUI, maybe I didn't use this function correctly ?

[argumentum]

..nah. It was a thought. But applied to a UDF that itself changes everything. It was thoughtless of me. Even without the UDF it would not fix everything.
Fortunately you found a solution.