Sign in to follow this  
Followers 0
ces1a

Wrong Screen Resolution Displayed by Autoit Macros

7 posts in this topic

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.

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

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 by Bilgus

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

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 by RTFC

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by Bilgus

Share this post


Link to post
Share on other sites

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...

 

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by Bilgus
changed return type on Shcore.dll to long

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • nacerbaaziz
      By nacerbaaziz
      Hi dear
      I have a question
      about the display language of the system
      How can I get the current display language and how can I change it by autoit
      Of course, if this is possible
      Greetings to all and hope you help me
    • breakbadsp
      By breakbadsp
      AutoIT AU3info doeas not detect all gui objects uniquely for .NET GUIs developed in C#.
      this is not working now i am using COM windows approach for this, But its very difficult.
      Please let me know if anyone has done it before.
    • DLS
      By DLS
      I have a working script that changes the core affinity and process priority of multiples of a specific application I have running.  
      I have that part figured out.

      I would like to make a little modification to it.

      Windows10 introduced virtual desktops.  I am trying to have different core affinity and priority of processes on the visible and non-visible desktops.  
      What I need is a bool function that could be described as IsWindowOnCurrentDesktop($hWnd).  I have searched the winAPI.au3 but I do not believe anything like that exists built it.
      I have searched multiple places before asking for help. I found a Microsoft supplied example of the function I need using C#, but I am unfamiliar with C# to a degree that I cannot port the system call over.
      https://blogs.msdn.microsoft.com/winsdk/2015/09/10/virtual-desktop-switching-in-windows-10/
      Help is appreciated but not expected.  Thanks in advanced.   In the meantime I will be learning C# syntax and class structure.
    • ur
      By ur
      With _WinWaitActivate we can wait for a window to process it.
      But is there any logic so that we can wait for this window title and based on the window text (like 2 or more patterns will be there) we can click yes or no on the window.
       
      Func _WinWaitActivate($title,$text,$timeout=0)
       WinWait($title,$text,$timeout)
       If Not WinActive($title,$text) Then WinActivate($title,$text)
       WinWaitActive($title,$text,$timeout)
      EndFunc
    • wtarkan
      By wtarkan
      If I create a service to run a program , Application window cannot Appear - How can I make the App window visible