Change 'DPI awareness' on runtime

[emileverh 21]

Hi guys!

 

I have a frustrating thing, in short; I have an application with lots of different users and thus different Windows installations ( 7-11 ). The problem with my app build with D11.2 is that I deployed it with: DPI Awareness - PER MONITOR V2'. Suddenly some customers are complaining that there where buttons totally 'off-screen'. I checked the system of a customer who had that problem and it was a 'new' laptop with Windows 11 installed and enough resolution for displaying everything. So it should not be a problem. When I set the DPI Awareness to NONE it worked.  But now are other customers complaining with same problem. It's sooooooooooo frustrating. 

 

Question; Is there a way to change the DPI AWARENESS in my application?!  So that I can read a (own) registry setting on startup and set the DPI AWARENESS to either PER MONITOR V2 or NONE.

 

Question; are there other suggestions to tackle this problem for once and for all?! 

 

Any help would but GREAT!

[dwrbudr 8]

Try 

SetProcessDpiAwareness(DPI_AWARENESS_CONTEXT_UNAWARE);

 

[emileverh 21]

6 minutes ago, dwrbudr said:

Try 

SetProcessDpiAwareness(DPI_AWARENESS_CONTEXT_UNAWARE);

 

Thanks a lot! I will give it a try. But still, it's a workaround. Does my problem sound familiar to you ( or other readers?)??

[dwrbudr 8]

You should put an effort to make your application DPI-aware. 

 

Here's a PDF that could help you understand the basics: https://www.helpandmanual.com/downloads_delphi.html

 

[emileverh 21]

19 minutes ago, dwrbudr said:

You should put an effort to make your application DPI-aware. 

 

Here's a PDF that could help you understand the basics: https://www.helpandmanual.com/downloads_delphi.html

 

I expect/hoped from Embarcadero that if I don't use any external manifest file and just turn on PER MONITOR V2 on in the project settings. That my executable is running fine on a modern ( read Windows 11 ) system. While reading some articles I saw that @Uwe Raabe recommended that ParentFont 'must' be set to true. But in this article  https://docwiki.embarcadero.com/RADStudio/Alexandria/en/High_DPI  is stated that for the Form ParentFont must be set to false. A bit confusing.....!!!  ( docwiki seems to be down, use cache ). I see that in my app ParentFont are a bit mixed. I might be the problem.....

[Remy Lebeau 1393]

2 hours ago, emileverh said:

I expect/hoped from Embarcadero that if I don't use any external manifest file and just turn on PER MONITOR V2 on in the project settings. That my executable is running fine on a modern ( read Windows 11 ) system.

Embarcadero's DPI handling is still quite broken.  They have taken several major releases to work on it, and it still has problems.  You are probably best off simply disabling DPI awareness at the project level, and then scale your UI in your own code as needed.

[emileverh 21]

52 minutes ago, Remy Lebeau said:

Embarcadero's DPI handling is still quite broken.  They have taken several major releases to work on it, and it still has problems.  You are probably best off simply disabling DPI awareness at the project level, and then scale your UI in your own code as needed.

Thanks Remy!  I hope that EMB read this and put all the resources that have in this to fix and test this. The is the core-core-core functionality. And yes, we all make mistakes, but let this be over for once and for all.

[rgdawson 8]

When creating DPI-Aware application you must take care when locating/sizing controls in code to adjust for the current DPI.  Buttons appearing off-screen sounds like that sort of problem.

 

For example,

 

Button.Left := MulDiv(X, Monitor.PixelsPerInch, 96), instead of Button.Left := X;

 

You will use MulDiv alot when making DPI-Aware apps.

 

 

[David Heffernan 2345]

There are probably issues in your code that are the real problem here, rather than it being an issue with the VCL. But there are certainly issues with the VCL too. Whether they impact you it's not clear. 

 

Certainly trying to set the dpi awareness at runtime, based on the os or some other environmental factor, is not the right solution. 

 

This is a complicated subject that needs a lot of understanding from developers, and testing. There's probably quite a bit of work required from you to understand the issues with the subject, and your specific app. 

 

It might also be a good time to concentrate on supported Windows versions and stop worrying about the pre Windows 10 users. 

[Attila Kovacs 629]

6 hours ago, rgdawson said:

You will use MulDiv alot when making DPI-Aware apps.

 

or you have a common form with some extra methods 🙂

[emileverh 21]

3 hours ago, David Heffernan said:

There are probably issues in your code that are the real problem here, rather than it being an issue with the VCL. But there are certainly issues with the VCL too. Whether they impact you it's not clear. 

 

Certainly trying to set the dpi awareness at runtime, based on the os or some other environmental factor, is not the right solution. 

 

This is a complicated subject that needs a lot of understanding from developers, and testing. There's probably quite a bit of work required from you to understand the issues with the subject, and your specific app. 

 

It might also be a good time to concentrate on supported Windows versions and stop worrying about the pre Windows 10 users. 

I am sorry, I don't agree on that. I have a Invoicing Application where I am talking about, so lots of database stuff and I do nothing with drawing on a canvas and doing fancy things.

 

So practical said; I am dropping (DevExpress) components on a form and I am running my applications ( yes I tried TForm and TdxForm). I also don't want to change the DPI awareness on runtime, but I am frustrated. For example now; my IDE (VCL Designer High DPI) is set to 96 DPI, this is not what I want but gives me the best results so far. Not good, but the best results.  ( When I look in my DFM's the PixelsPerInch  are 120 ).

 

For example now I have the situation with the above settings that running my app (on a Windows 11 machine) with 192 DPI I get panels overlapped, see attachment. This is not the way I designed it. On running on Windows 11 machines with lower resolution it looks okay. So RUNTIME SCALING IS NOT GOOD! I have lots of forms and most of them are okay. And I don't see where to look/to fix this.

 

And second; opening a form which was designed on a machine with different DPI settings can also mess up the DFM with strange coordinates. Don't say; report this to EMB. They must know this....

 

As @Remy Lebeau said they have to do some more work at EMB. This the(!) core ( read CORE) functionality. So I hope they will put all the resource they have on fixing this, rather then sending me a daily commercial mail.

[Attila Kovacs 629]

this looks strange, even a logical control hierarchy is missing, otherwise they would be cropped on the bottom

you should try using alignments instead of fixed positions

[emileverh 21]

1 minute ago, Attila Kovacs said:

this looks strange, even a logical control hierarchy is missing, otherwise they would be cropped on the bottom

you should try using alignments instead of fixed positions

As I said, and this is what I want, just drop a component on form and run it... So yes, I am using the default Alignment and Anchors. And I definitely not want to do set component positions on runtime. DELPHI supposed to be a RAD application. 

[David Heffernan 2345]

Personally I think it's unrealistic to expect to be able to solve this problem without understanding it, but I can see why people might want to do that. Anyway, good luck with this, I hope it works out for you. 

[emileverh 21]

1 minute ago, David Heffernan said:

Personally I think it's unrealistic to expect to be able to solve this problem without understanding it, but I can see why people might want to do that. Anyway, good luck with this, I hope it works out for you. 

FYI as I read the comments I don't gonna implement the call : SetProcessDpiAwareness (DPI_AWARENESS_CONTEXT_UNAWARE);      I think that I am gonna be further from home. I hope EMB has in 11.3 fixed more of the High DPI issues. 

[Lajos Juhász 293]

You can also test with regular VCL controls, the bug could be also in the DevExpress controls. With VCL placed on the form I don't have had placement problems.