Devexpress Dpi Awareness

2 views
Skip to first unread message

Hyun Orth

unread,
Aug 4, 2024, 8:11:45 PM8/4/24
to sayhiomeli
Thisarticle explains how to develop DevExpress-based applications that can be viewed on high DPI devices without loss of quality. For more information about what DPI is and how different Windows versions scale your applications on high resolution displays, refer to the following links:

Do not use the Microsoft Windows graphics device interface (GDI) before the application is set as DPI-aware. This may lead to unexpected behavior. That is, do not use any graphic objects such as Bitmaps, Brushes, or Fonts. Also, do not invoke any subsystems that might use them (for example, do not apply a skin to the application).


Call the static (Shared in VB.NET) WindowsFormsSettings.ForcePaintApiDiagnostics method to ensure DPI awareness is activated correctly. See the following section for more information: Troubleshooting.


Visual Studio should run on a standard 96 DPI screen. If you must create your application at a resolution greater than 96 DPI, see the following KB article for additional guidance: How to improve the Visual Studio WinForms Designer experience on High DPI.


Create custom-sized UI controls (for example, PopupContainerControl) in the Visual Studio Designer for Per Monitor (V2) applications to avoid scaling issues (do not specify the size of UI controls in code).


Since your app needs to resize according to display DPI values, keep the layout flexible. If possible, use LayoutControl, TablePanel, and StackPanel containers that auto-adjust the layout of controls when the parent container size changes.


To trace all APIs that are not recommended for use with DirectX-rendered and Per-Monitor DPI-aware applications, call the static WindowsFormsSettings.ForcePaintApiDiagnostics method and set the security level as the first parameter:


To reduce traffic consumption and improve overall performance in remote environments, you can selectively disable optional effects. See this blog post for more information: WinForms Tips & Tricks - Boosting Application Performance.


Now i have a Winform application (.NET Framework 4.8) using DevExpress that use an embedded CefSharp browser and as soon as the embedded browser loads the specified url, i can see a blink of that windows form and the zoom of that windows form become "according to the second monitor" (100% zoomed).


I read that DPI awareness could be involved in this issue. Is it possibile?But for a simple reason (Application is quite old and a quite full of features to maintain) my application cannot consider DPI awareness, so i accept to see a pixeled imaages.


I have tried to set the DPI Awareness (PerMonitorV2) with DevExpress and with with "classical windows form way" (app.manifest) but the font and layout become too big (or too small) and it is not "automatically" resized to 100% then to 125% alternatively.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.

3a8082e126
Reply all
Reply to author
Forward
0 new messages