HiRes_DPI settings via Autoit3Wrapper

[Shark007]

I have done extensive, worldwide testing and suggest the following change to the DPI section of AutoIt3Wrapper.au3.
I publish free software (updates released twice+ weekly) with 10's of thousands of users to substantiate the worldwide statement.
This covers ALL versions of Windows that support DPI scaling and is ignored by Windows version that do not support it.

Replace the entire DPI section with the following...

If $INP_RES_HiDpi = "y" Then
    Write_RC_Console_Msg("Setting DPI awareness Manifest information to true", "", "...", 0)
    FileWriteLine($hTempFile2, '<asmv3:application>')
    FileWriteLine($hTempFile2, '    <asmv3:windowsSettings>')
    FileWriteLine($hTempFile2, '        <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>')
    FileWriteLine($hTempFile2, '        <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>')
    FileWriteLine($hTempFile2, '    </asmv3:windowsSettings>')
    FileWriteLine($hTempFile2, '</asmv3:application>')
EndIf

As you wish.

Edited February 23, 2021 by Shark007

[Jos]

23 minutes ago, Shark007 said:

Replace the entire DPI section with the following...

Would be great when that really works for "Most" people as till now each proposal have had drawbacks.
Lets see if anybody can think of any issue with this or has issues when testing this mod.

Thanks for your input!
Jos

[Shark007]

I think that people using this need to understand that setting an application to be DPI aware
only deals with the text of the application. The GUI itself and all of its controls needs to be dealt with as outlined
here: https://www.autoitscript.com/forum/topic/199786-making-your-compiled-application-dpi-aware

Edited February 23, 2021 by Shark007

[Jos]

Your proposal is basically what is already in AutoItWrapper but currently commented out due to 

Quote

; ----- reverted this change as it is giving some issues. Needs investigation

which was back in 2018 when @jpm made a proposal for some changes...., but I have no idea anymore what the issue was. 

Edited February 24, 2021 by Jos

[Shark007]

I didn't even look at the commented code,  but I did I know of its existence.

This one is way over my head but I want to present the idea to Jos in case it is possible.

When a user chooses to make their application DPI Aware,
The compiler automatically adjusts x, y, width, height
by multiplying those coordinates using the results of the following:

Func DPIRatio()
    _GDIPlus_Startup()
    Local $hGfx = _GDIPlus_GraphicsCreateFromHWND($MyApp) ; edit $MyApp to be your GUI
    Local $aResult = DllCall($__g_hGDIPDll, "int", "GdipGetDpiX", "handle", $hGfx, "float*", 0)
    _GDIPlus_GraphicsDispose($hGfx)
    _GDIPlus_Shutdown()
    If $aResult[2] = 0 Or '' Then
        Return 1
    Else
        Return $aResult[2] / 96
    EndIf
EndFunc   ;==>DPIRatio

Then the user would not need to deal with any scaling of the GUI and its controls.
I think that in the past, this is where people concluded it didn't work properly.

Edited February 23, 2021 by Shark007

[Shark007]

@Jos If you're considering implementing my 2 suggestions posted here, (especially including the DPIRatio Func)
I'd be more than happy to privately test any new AutoIt3Wrapper.au3 you come up with.

[Jos]

20 hours ago, Shark007 said:

@Jos If you're considering implementing my 2 suggestions posted here, (especially including the DPIRatio Func)
I'd be more than happy to privately test any new AutoIt3Wrapper.au3 you come up with.

One thing we could consider is add an option to #AutoIt3Wrapper_Res_HiDpi. We currently have Y/N/P were "P" adds the "/PM" . So the AutoIt3Wrapper code would be:

If $INP_RES_HiDpi <> "n" Then
    FileWriteLine($hTempFile2, '    <asmv3:application>')
    FileWriteLine($hTempFile2, '        <asmv3:windowsSettings>')
    If $INP_RES_HiDpi = "p" Then
        Write_RC_Console_Msg("Setting DPI awareness Manifest information to true/PM", "", "...", 0)
        FileWriteLine($hTempFile2, '        <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>')
        FileWriteLine($hTempFile2, '        <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>')
    Else
        Write_RC_Console_Msg("Setting DPI awareness Manifest information to true", "", "...", 0)
        FileWriteLine($hTempFile2, '        <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True</dpiAware>')
    EndIf
    FileWriteLine($hTempFile2, '        </asmv3:windowsSettings>')
    FileWriteLine($hTempFile2, '    </asmv3:application>')
    FileWriteLine($hTempFile2, '')
EndIf

Then when you use #AutoIt3Wrapper_Res_HiDpi=p you will get the result as you want.
This way we keep the current standard behavior for "Y" to ensure we don't break anything.

Jos

 

Edited February 24, 2021 by Jos

[Shark007]

2 hours ago, Jos said:

One thing we could consider is add an option to #AutoIt3Wrapper_Res_HiDpi. We currently have Y/N/P were "P" adds the "/PM" . So the AutoIt3Wrapper code would be:

Then when you use #AutoIt3Wrapper_Res_HiDpi=p you will get the result as you want.
This way we keep the current standard behavior for "Y" to ensure we don't break anything.

Jos

 

True = Windows 7 -- /PM is support for Windows 8 -- PerMonitorV2 = latest versions of Windows 10 -- PerMonitor = Wimdows 8.1 and early versions of 10

Giving /PM its own status is redundant. Windows 7 ignores its presence and Windows 8 will use True unless /PM is present, then it will use PerMonitor

The code below covers all versions of Windows simultaneously if present and each version of Windows will choose what is the best option for itself.

FileWriteLine($hTempFile2, '        <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>')
    FileWriteLine($hTempFile2, '        <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>')

The code above is what you should be using when a user selects to enable #AutoIt3Wrapper_Res_HiDpi=y

It would be AN ABSOLUTE BONUS if you incorporated the DPIRatio Func I posted to adjust the x,y,w,h parameters of the GUI  and its contols when HiDPI is enabled. You just need to multiply each x,y,w,h by the DPIRatio result and you will have perfect support for all DPI scenario's.

Edited February 24, 2021 by Shark007

[Melba23]

Jos,

If you could incorporate a DPIRatio function as suggested - so that the user had access to known variables to use to adapt their coordinates - I would consider that a very elegant solution to the DPI problem we suffer at present. 

If you were to produce a Beta I would be happy to join @Shark007 in testing it.

M23

[Jos]

I must say I am lost on how that func would need to be implemented as I assumed it is needed in the script itself, so could any of you help me understand how this could work when implemented in Autoit3Wrapper?

[Melba23]

Jos,

Ah yes - I did not think that through enough!

Perhaps if you were to get the Wrapper to add the whole DPIRatio function to the script (using an obscure name to prevent errors) and set the results into 2 suitably-named global variables (for x and y coordinates). The user would then create his GUI and control using the preferred coordinates but using these variables to adjust them as required - something like this:

GUICreate("DPI Aware", $iX * $gAutoItWrapper_DPIAware_X, $iY * $gAutoItWrapper_DPIAware_Y, $iW * $gAutoItWrapper_DPIAware_X, $iH * $gAutoItWrapper_DPIAware_Y)

How does that sound?

M23

[Shark007]

To give you some idea of how I use it, 

Global Const $iScale = DPIRatio()

Func DPIRatio()  ; match screen resolution
    _GDIPlus_Startup()
    Local $hGfx = _GDIPlus_GraphicsCreateFromHWND($SetApp)
    Local $aResult = DllCall($__g_hGDIPDll, "int", "GdipGetDpiX", "handle", $hGfx, "float*", 0)
    _GDIPlus_GraphicsDispose($hGfx)
    _GDIPlus_Shutdown()
    If $aResult[2] = 0 Or '' Then
        Return 1
    Else
        Return $aResult[2] / 96
    EndIf
EndFunc   ;==>DPIRatio

 

There is over 500 instances of $iScale

Edited February 24, 2021 by Shark007

[Melba23]

Shark007,

Even simpler than I thought - just the one variable needed.

M23

[Jos]

5 minutes ago, Shark007 said:

To give you some idea of how I use it, 

Thanks, but let's focus on what autoit3wrapper can do for the users script, as all of this needs to happen in the users script and not in autoit3wrapper. 

@Melba23 proposal is one that could be done, but I am still wondering why it should be done by autoit3wrapper and not in the script itself?

Just trying to get my head around what it is we want to accomplish where. 

Edited February 24, 2021 by Jos

[Shark007]

Anytime DPI is in use, the GUI needs this to be visually correct.

[Jos]

Understood...but did you answer my last post with this answer? 🤔

 

 

[Shark007]

How about a simple parameter as what was used in the past to enable /PM

The only real variable is the handle to the GUI being created. AutoIt Wrapper cant get that during compile?

_GDIPlus_GraphicsCreateFromHWND($SetApp)   ; $SetApp is the variable I use when creating the GUI parameters.

[Jos]

I am sorry, but I still do not see what Autoit3wrapper can do here so you need to answer the question I asked before: isn't that something that needs to happen in the users riot at run time? ...  And what can Autoit3wrapper do here to help the user at compilation/run time?

Sorry,  but I am really lost here as stated earlier.

[Shark007]

It was my hope/wish that AutoWrapper could eliminate the need for the user to apply all of this scaling themselves.
Most users, enable HiDPI through Scite, see that their GUI is all F'd up and move on.
If the Wrapper could do some magic to the x,y,w,h parameters, more people would be inclined to use the DPI setting.

Edited February 24, 2021 by Shark007

[Jos]

So how would all of that work when they only compile and run the script as stand alone binary. ...  But even when using run, it is a separate instance of AutoIt3 so autoit3wrapper would have to modify the source of the script... Right?