Wrong Screen Resolution Displayed by Autoit Macros

[ces1a]

I recently upgraded my laptop to one with Windows 10 and higher screen resolution.  In the process I found that some of my scripts did not work right when using Autoit's @DesktopWidth and @DesktopHeight macros.  Insteat of 1920 x 1080 resolution Autoit detects 1536 x 864.  Thus, GUIs designed to appear near the right edge of the screen  displayed closer to the horizontal middle of the screen.  I assume others may have the same problem.

A search on this forum and Microsoft Script Center helped me to write the following script that gets the true screen width and height from WMI.

MsgBox(0, '', _GetMonitorInfo())

Func _GetMonitorInfo()
    Local $oWMI, $Listing, $sWidth = 0, $sHeight = 0
    $oWMI = ObjGet("winmgmts:\\" & @ComputerName & "\root\CIMV2")
    If IsObj($oWMI) Then
        $Listing = $oWMI.ExecQuery("SELECT * FROM Win32_DesktopMonitor")
        If IsObj($Listing) Then
            For $oItem In $Listing
                $sHeight = $oItem.ScreenHeight
                $sWidth = $oItem.ScreenWidth
            Next
        EndIf
    EndIf
    Return "Width: " & $sWidth & @CRLF & "Height: " & $sHeight
EndFunc ;_GetMonitorInfo

Hopefully it will benefit others.  I for sure am very happy with all the samples I been able to find here in the past.

[Bilgus]

Have you tried adding:

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

Then when you compile the code this works on W7 and 8 at least Could you try it on your win 10 install 

Edited May 11, 2016 by Bilgus

[RTFC]

This can happen when Win10 auto-rescales (see under display settings, I think 125% is default for 1920x1080) to make them easier to read (as hi-res screens make everything that used to look about the right size look tiny now). To make your original script work in full resolution (with macros returning the correct (full) dimensions), while maintaining rescaling for regular programmes, add:

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

This causes the script to take advantage of the full current resolution, but at the cost of its text and graphics appearing smaller than if running rescaled.

Edited May 11, 2016 by RTFC

[Bilgus]

3 hours ago, RTFC said:

This can happen when Win10 auto-rescales (see under display settings, I think 125% is default for 1920x1080) to make them easier to read (as hi-res screens make everything that used to look about the right size look tiny now). To make your original script work in full resolution (with macros returning the correct (full) dimensions), while maintaining rescaling for regular programmes, add:

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

This causes the script to take advantage of the full current resolution, but at the cost of its text and graphics appearing smaller than if running rescaled.

Hey, Thanks.

Noted This: https://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx

Note  SetProcessDPIAware is subject to a possible race condition if a DLL caches dpi settings during initialization. For this reason, it is recommended that dpi-aware be set through the application (.exe) manifest rather than by calling SetProcessDPIAware.

 

So it sounds like something like this is in order.

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

If Not (@Compiled ) Then DllCall("User32.dll","bool","SetProcessDPIAware")

 

 

Edited May 11, 2016 by Bilgus

[RTFC]

@Bilgus: good point, duly noted, and thanks. I only ever tested this running from Scite.

[ces1a]

Thanks a lot to everyone.

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

The above lines seem to make my executable unable to run.  I have not figured out why yet.

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

Lets my script run but causes distortion to my labels,

However, looks like this is the right direction to go.

Thanks a million...

 

[Bilgus]

I know turning scaling off would change your labels not sure about the app not running with the manifest entry added though.

I wonder if maybe it has something to do with this: 'SetProcessDPIAware is available for use in the operating systems specified in the Requirements section. It may be altered or unavailable in subsequent versions. Instead, use SetProcessDpiAwareness'

SetProcessDpiAwareness: https://msdn.microsoft.com/en-us/library/windows/desktop/dn302122(v=vs.85).aspx

It seems to have the same caveats as SetProcessDPIAware as in placing in manifest rather than calling the function directly,

it also isn't available till win 8 and later.

Perhaps W10 won't work with the older function in the manifest which I find odd. If so,  I think additions to the manifest or logic would be something that would have to be updated in the Autoit  Res_HiDpi Pragma

Maybe someone more knowledgeable with aut2Exe  would be able to inform us on that.

For the time being maybe you should use either your current function or maybe do something like this:

If @OsType="WIN_10" Then
    DllCall("Shcore.dll","long","PROCESS_DPI_AWARENESS",1) 
Else
    DllCall("User32.dll","bool","SetProcessDPIAware") 
EndIf
;hResult is 32bit

;PROCESS_DPI_UNAWARE = 0, PROCESS_SYSTEM_DPI_AWARE = 1, PROCESS_PER_MONITOR_DPI_AWARE  = 2

Not sure if I got that dll call right I'm not near a PC to test atm.

Also, Not necessarily directed at you:
I'm unsure how likely it is that a Dll would cache the dpi data.

Would the Dll be something called by Autoit or the OS. 

What exact situation would result in this Race Condition and what are the consequences?

Be something to look into as the MSDN page is kind of vague.

Edited May 14, 2016 by Bilgus
changed return type on Shcore.dll to long