HiRes_DPI settings via Autoit3Wrapper

[Shark007]

When the user selects to use HiDPI, couldn't the Wrapper just apply the scaling during build without modifying the script?

[Melba23]

Jos,

Quote

so autoit3wrapper would have to modify the source of the script... Right?

Exactly. My idea was that the Wrapper when compiling would actually add the code for the DPIRatio function to the script in the same way as when using an #include directive - if not compiling then the function would be run by the Wrapper itself. Then whenever the script is run, the DPIRatio function would run and the correct ratio would be determined for the script on that particular machine.  If the DPI flag was not set then nothing would be added to the script when compiled, nor calculated internally if merely running the script.

The user would then use that ratio to correct the various coordinates - as shown by the code image Shark007 posted above. The Wrapper would not need to do any modification of the coordinates itself - merely calculate the ratio for the user to use.

M23

Edited February 24, 2021 by Melba23
Added final paragraph

[Melba23]

Shark007,

Quote

couldn't the Wrapper just apply the scaling during build

That would certainly require a massive parsing effort to find each possible coordinate parameter to which the correction should be applied, thus slowing the execution/compile time enormously. Just getting the Wrapper to add the function to compiled code - or do the calculation itself if running a script - seems to me a much more realistic approach.

M23

[Shark007]

Well, I tried.

I have no need for this myself because as you can see, I have worked around the issue using the $iScale variable. I was just hoping to help others not go through the headaches that I did in order to come up with an actual working AutoIt script that uses Windows DPI solutions.  Any resourceful scripter will find my posts about this easy enough.

[Melba23]

Shark007,

Quote

Well, I tried

Not so fast - you have not (yet) failed in your endeavour. If Jos agrees with my proposal then coders will have easy(ish) access to the DPI scaling constant which can be used as you yourself use it at present. If he agrees to your manifest changes then that makes for a pretty comprehensive solution to the AutoIt DPI problem. A 90% solution which does not unduly hamper the non-DPI working of the Wrapper seems to me to be a pretty good step forward.

M23

[Jos]

Guys, you are miles ahead of me, which I have tried to explain now several times. I need to understand first what needs to happen where before I can even start considering solutions, so can we please start there with some simple example and answers to my questions?

So what about we take a simple helpfile example as basis and you explain what would need to be done to it for this all to work?

Thanks!

 

 

Edited February 25, 2021 by Jos

[Shark007]

#1, fix the implementation of DPI usage in the Wrapper
https://www.autoitscript.com/forum/topic/205059-7022021-uploaded-a-new-release-candidate-of-the-new-scite4autoit3exe-v2120315003/?do=findComment&comment=1475840
I said,
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.I showed my work,
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

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

You said,
Understood...

Then I said,
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.

Then I said,
Well, I tried.

I have no need for this myself because as you can see, I have worked around the issue using the $iScale variable. I was just hoping to help others not go through the headaches that I did in order to come up with an actual working AutoIt script that uses Windows DPI solutions.  Any resourceful scripter will find my posts about this easy enough.

and here we are... I do not know where you will take this information, but it is available to you.

I am not in a postion to modify the wrapper.

Edited February 24, 2021 by Shark007

[argumentum]

1 hour ago, Shark007 said:

I am not in a postion to modify the wrapper.

But you are in position. Just do it, show it, and if is approved then it is.
Heads up, it can be a lot of work.

...and I've done such things, and some got liked and some did not, so, I'm not saying that it will, but if it proves a point, do it.

[Shark007]

Here is a simple test script. 
The current Wrapper does not give you access to any of the Windows 10 Microsoft enabled DPI enhancements.
You will need to modify your Wrapper as I outlined earlier.

You can easily toggle the DPI enablement and the effect of adding the scaling at 1:1 or using the Func

The default of this script, $iScale = 1:1 is what you get without the scaling enabled

If your screen is not set to scale It will not be a test. The greater the scaling, the greater the difference.

To set a scaled screen, rightclick the desktop, choose 'Display settings
Directly under Scale and layout, you can set a scaling factor

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Res_HiDpi=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

#include <GDIPlus.au3>
Opt('GUICloseOnESC', 1)

Global $TestApp

Global Const $iScale = 1
;Global Const $iScale = DPIRatio()

Func DPIRatio()
    _GDIPlus_Startup()
    Local $hGfx = _GDIPlus_GraphicsCreateFromHWND($TestApp)
    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

$TestApp = GUICreate('testing', 500 * $iScale, 300 * $iScale, -1, -1) ;if x,y coordinates are specified, they need the scaling also.
GUICtrlCreateButton("<This is just a test>", 38 * $iScale, 140 * $iScale, 200 * $iScale, 25 * $iScale)

GUISetState(@SW_SHOW)

While 1
    Switch GUIGetMsg()
        Case -3
            Exit
    EndSwitch
WEnd

For completeness, my main development system has a 4K screen set at 225% scaling, and I also test on a 1080p laptop set at 150%.
Both of these systems have multi-choice boot menu's containing
Window 7, Windows 8.1, Windows 10 20H1/2, Windows Dev and just today I installed , Windows 10 21H1 onto the laptop.

Edited February 25, 2021 by Shark007

[Jos]

I see some emotions popping up and that was not the intention, merely needed verification I understood what is expected.
So let me answer my own last request using the last example giving:

So we have this script and somebody hits F5/F7 on this "before" script:

#AutoIt3Wrapper_Res_HiDpi=y
Opt('GUICloseOnESC', 1)

Global $TestApp

$TestApp = GUICreate('testing', 500, 300, -1, -1) ;if x,y coordinates are specified, they need the scaling also.
GUICtrlCreateButton("<This is just a test>", 38, 140, 200, 25)

GUISetState(@SW_SHOW)

While 1
    Switch GUIGetMsg()
        Case -3
            Exit
    EndSwitch
WEnd

.. and the expectation is that it will be changed to something like this "after" script adding/changing all the missing bits:

#AutoIt3Wrapper_Res_HiDpi=y

#include <GDIPlus.au3>  ;### Added by Res_HiDpi
Opt('GUICloseOnESC', 1)

Global $TestApp

;### Start Added by Res_HiDpi ###
Global Const $iScale = DPIRatio() 
Func DPIRatio()
    _GDIPlus_Startup()
    Local $hGfx = _GDIPlus_GraphicsCreateFromHWND($TestApp)
    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
;### End Added by Res_HiDpi ###

;### Commented by Res_HiDpi: $TestApp = GUICreate('testing', 500, 300, -1, -1) ;if x,y coordinates are specified, they need the scaling also. 
$TestApp = GUICreate('testing', 500 * $iScale, 300 * $iScale, -1, -1) ;### Added by Res_HiDpi
;### Commented by Res_HiDpi:  GUICtrlCreateButton("<This is just a test>", 38, 140, 200, 25)
GUICtrlCreateButton("<This is just a test>", 38 * $iScale, 140 * $iScale, 200 * $iScale, 25 * $iScale) ;### Added by Res_HiDpi

GUISetState(@SW_SHOW)

While 1
    Switch GUIGetMsg()
        Case -3
            Exit
    EndSwitch
WEnd

Well that is not going to happen in autoit3wrapper itself as I feel it doesn't belong there, but when someone has the drive to write a utility for it, it could easily be included like I've done with Tidy/Au3Stripper which also modify the source file. 
Looking at it I don't think this will be a trivial thing as you need to detect which parts are missing and need to be added in the right spots, but anything is possible when you put your mind to it!  

Jos

 

Edited February 25, 2021 by Jos

[Shark007]

My idea is that this $iScale stuff would all occur at build time, virtually, without modifying the users script.

[Jos]

14 minutes ago, Shark007 said:

My idea is that this $iScale stuff would all occur at build time, virtually, without modifying the users script.

Sorry , but I lost you there as in my mind one will have to build the "after" source as shown for it to work...right? 
So I have no idea what virtually means in this context unless you mean to build a new updated scriptfile with these changes, like Au3Stripper does?

The way I look at this is that a new utility script will take the original script and modifies the code in a way that clearly shows what it has changed, as I tried to show  in the "after" script. Like Au3Stripper, the output script can then be  put in a new file e.g. OriginaleScriptName_hipdi.au3 for processing. 

This all should be doable in an autoIt3 script but will require some effort to get there. 

Jos 

[Shark007]

Yes, just like Au3Stripper. A dream come true.

Although functional, having over 500 occurrences of $iScale in my script(s) is a bit ridiculous.

[Jos]

I think the untested example I posted  is wrong as I see you use the GUI handle as global variable and use it in DPIRatio.
Do you need to call func DPIRatio() for each defined GUI separately? I would think that you only need to calculate the $IScale one time...right? 

Jos

PS: Split of this discussion into its own thread.

Edited February 25, 2021 by Jos

[Shark007]

 I am no professional when it comes to scripting.
My work is usually based on someone else's work that I have modified to meet my needs.
I set the App as a global variable to get around undeclared variable messages.

You are correct; the scaling only needs to be calculated once.

[Jos]

5 hours ago, Shark007 said:

I am no professional when it comes to scripting.

Me neither....  just a hobbyist here  

.... but something like this could be a start:

-snip- Updated the source and posted in a later post..

Just need to add all possible GUI* functions to it and maybe there are ideas to make the RegEx tests simpler.

Jos

edit: Source updated with comments and some fixes 

Edited February 25, 2021 by Jos
Added comments in source

[InnI]

2 hours ago, Shark007 said:

the scaling only needs to be calculated once

If you set Per-Monitor or Per-Monitor (V2) DPI Awareness then you must to resize and reposition the controls each time when receive WM_DPICHANGED message. Otherwise, the controls will match the DPI of the primary monitor, while other monitors may have different DPI.

[Shark007]

4 minutes ago, InnI said:

If you set Per-Monitor or Per-Monitor (V2) DPI Awareness then you must to resize and reposition the controls each time when receive WM_DPICHANGED message. Otherwise, the controls will match the DPI of the primary monitor, while other monitors may have different DPI.

An excellent point to make because I have dragged my GUI under Windows 10 from 150% scaling onto a monitor @ 225% scaling and there was minor discrepancies in the visual representation.

[Jos]

 

As you see ....there seem to be more and more variables here to take into account so which the person luck with finding a solution that fits All/Most.
I am not going to do more development on this as I do not use this myself, so have no way to properly test. 

Jos

[Shark007]

So, using the information provided by InnI, I did some quick research.
I added this to my script and it seems I have no more discrepancy when dragging from one DPI to another

GUIRegisterMsg(0x02E0, 'DPIRatio')

While 1
    Switch GUIGetMsg()
        Case -3
            Exit
        Case 0x02E0
            DPIRatio()
    EndSwitch
WEnd

This change has also solved the issue of changing the DPI while the GUI is open. THANKS InnI.

Edited February 25, 2021 by Shark007