What exactly does HiDpi=Y set? ... and where?

[qwert]

Once again, I'm delving into the strange—and changing in Win10—realm of High DPI Displays.  Things that I thought were settled seem back in play.

As a test, I prepared two simple GUIs ... one with HiDpi=Y ... and with HiDpi=N.

They ARE treated differently on a Win10 PC running at 125%.  But the DPI parameters in Properties show exactly the same settings: nothing is set.  Yet by changing the settings in Properties, I can change the displayed GUI on that PC.

So, what does, exactly, does #AutoIt3Wrapper_Res_HiDpi=Y do?  I couldn't find a definitive answer in any post.

Any help will be appreciated.

 

 

Edited June 2, 2018 by qwert

[qwert]

I'll try once more.  Does anyone know?

What, exactly, does #AutoIt3Wrapper_Res_HiDpi=Y do?

[qwert]

This remains the #1 question in my quest to understand the choices for managing GUIs for HiDPI displays.

The week, I've experienced Win10 showing the opposite for installed EXEs:

With NO wrapper setting, Win10 shows "Override ... with scaling performed by Application"

On an EXE where HiDpi-Y, Win10 shows "Override ... with scaling performed by System(Enhanced)"

Does anyone know why this might be?

[LarsJ]

#AutoIt3Wrapper_Res_HiDpi=Y makes your program DPI aware through an application manifest. See this thread and Microsoft documentation.

Edited September 20, 2018 by LarsJ
Wrong link

[qwert]

@LarsJ: thanks for your response.

The link you listed led me to this page that seems to represent the latest from MSFT: latest

It's obvious that there's a lot involved ... including a new "mixed-mode DPI scaling".  Plus, it's disconcerting that MSFT includes this statement:

Quote

We recommended that you specify the default process DPI awareness via a manifest setting. While specifying the default via API is supported, it is not recommended.

What I'm currently experiencing (and investigating) is that when Win10 interprets an EXE's manifest and shows the DPI scaling settings in the Properties dialog, it's different from what I declared at compile time. It's why I'm trying to follow what's set in the EXE's manifest and then figure what else is coming into play.

Probably worst of all is that I've found that a GUI-based EXE will run fine on its own ... but will display its GUI incorrectly when run from one of my EXEs that has the opposite HiDpi setting (a script without a GUI, for example). It's like the DPI scaling is somehow inherited. (This is all under Win10, BTW ... but running EXEs that are compiled on Win7.)

Anyway, I appreciate the information and will post what I eventually find.

 

[Jos]

On 7/24/2018 at 1:28 AM, qwert said:

I'll try once more.  Does anyone know?

What, exactly, does #AutoIt3Wrapper_Res_HiDpi=Y do?

Sure, and pretty easy to figure out too as autoit3wrapper.au3 contains the logic.

All it does is add this to the manifest of the compiled program:

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

The option can be N/Y/P  or No/Yes/PM.
The details are explained on the Microsoft site as you have found already i guess.

Jos

[qwert]

@Jos, thanks for the clarifications.

At this point, I'm a little disoriented by the results I'm seeing. For example, MSFT's Process Explorer shows DPI Awareness = Unaware on Win10 for the EXE's that I compiled with HiDpi=Y.

But the biggest possible (probable?) factor is that I'm running 2017 versions of Au3 and SciTE.  Before I continue, I'm going to upgrade to 3.3.14.5 so that anything I determine is completely current.

This might take me a couple of days, since my development environment is pretty complicated. And just to clarify: I build on Win7 ... run on Win7 and Win10 ... on both HiDPI and normal monitors (but not both at the same time ... at least not yet).

Thanks, again.

 

[Jos]

No need to upgrade your current setup. Just download the zip version of the latest Autoit3 and store it in a separate directory. Then add this directive to the scrip and point it to this separate setup:

#AutoIt3Wrapper_AutoIt3Dir=

Compile the script and your in business. This should have no impact and makes testing easy.

Jos

Edited September 20, 2018 by Jos

[qwert]

1 hour ago, Jos said:

No need to upgrade your current setup.

What a welcome bit of advice! ... "wow", actually.  I've been using AutoIt3 for almost 10 years and that directive never entered my view.  (I guess I can stop dreading upgrades!)

Thanks, Jos.

[mLipok]

As far as I know/remeber this solution worsk but compiled program must be run on Win8.1 or Win10 

 

Edited September 20, 2018 by mLipok

[LarsJ]

Docu: High DPI Desktop Application Development on Windows

[qwert]

OK, I've recompiled my test script with the latest Au3 and the manifest section of both EXEs is exactly the same:

But MSFT's page indicates the manifest should now have BOTH awareness parameters:

Is there a compiler setting for this?

Edited September 21, 2018 by qwert

[Jos]

39 minutes ago, qwert said:

Is there a compiler setting for this?

Obviously not (yet).

What about when you try modifying the lines in AutoIt3Wrapper to what you think it should be, test to see if it all works and send me the new version so I can merge it into the current version?

Jos

 

[qwert]

2 minutes ago, Jos said:

what you think it should be

I'd love to be able to do that with any confidence. But I was just looking at the AutoIt3Wrapper.au3 statements and immediately I'm not at all clear on how to handle /SMI/2005/ versus /SMI/2016/.  Specify only the latest? Or use both in different segments of statements?

I'll be glad to make changes and run tests, but I'm facing these questions. Can you recommend a proper course?

[Jos]

Ok, replace the section I posted with this and see if that works for you:

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

I have no means of testing so am stabbing in the dark here...

Jos

[qwert]

Will do.  But I'm going to pause for a couple hours and think over the choices one more time.  The statements you've posed don't specifically cover the ones I thought I was concerned with at this point:

<dpiAwareness>unaware</dpiAwareness> ... so system handles DPI differences by default

<dpiAwareness>system</dpiAwareness> ... so system handles DPI difference by a clear directive

But it does appear that <dpiAwareness>PerMonitorV2</dpiAwareness> covers the general case of "Application is Aware" (and will handle differences in DPI ... which is the old HiDPI=Y).

[Jos]

Sounds good. I haven't read up on all options for this so need to understand what they all are now to be able to produce the right logic/option for the directive.
So any input there is welcome.

Jos

[jpm]

Hi,

for me the proposed solution does not work, only the previous version which is commented today is working

[Jos]

JP, Doesn't the solution provided in PM work either?