Hi,
We are trying to make our winforms app dpi aware, but we are having trouble when we use the UltraDockManager.
The areas and panes do not scale, and so everything gets crushed (for example the font increases in size for the titles, but the depth and width of the title bar has not been scaled).
Is there something I am missing, or do I need to find an alternative to the Dock Manager?
Hi Simon,
When the DPI Aware setting is enabled, all of the automatic scaling that Windows does is disabled. This is because the DPI Aware setting tells Windows that this application knows to check for the system DPI and respond based on the current DPI settings. You may be seeing these issues if you have not yet accommodated for DPI settings in your application. You can read more about writing DPI Aware applications here: https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx
That being said, we have heard of DPI-related artifacts that appear to be related to an issue in our tool. We are actively working to isolate this issue so we can resolve it. Are you able to send a reproduction sample that we can use to debug? Please include as much information about your environment as possible -- this issue appears to be very sensitive to system settings.
I created a little test app to see what controls are giving me issues.
I started with just the UltraButton and UltraTab controls and they rendered fine on my laptop (screen DPI set at 192, scaling at 200%)
I then added the UltraDockManager as we rely heavily on that, and this is when the issues started with the scaling of the title bars, and the width of the panels.
Hi Mike,
I have picked this issue up and added your debug code to the sample app.
Running at a screen resolution of 1920 x 1080 at a DPI of 96 I get the following output:
BottomPane: {Width=622, Height=145}Log: {Width=622, Height=121}Debug: {Width=0, Height=0}LeftPane: {Width=195, Height=221}SystemExplorer: {Width=195, Height=197}FileExplorer: {Width=0, Height=0}Favourites: {Width=0, Height=0}CurrentWindows: {Width=0, Height=0}RightPane: {Width=195, Height=221}Properties: {Width=195, Height=221}ultraButton1: {Width=75, Height=24}ultraButton2: {Width=75, Height=23}ultraTabControl1: {Width=330, Height=241}
Comparing this to a screen resolution of 2880 x 1620 at a DPI of 192 (200%) I get the following output:
BottomPane: {Width=1244, Height=145}Log: {Width=100, Height=100}Debug: {Width=100, Height=100}LeftPane: {Width=195, Height=592}SystemExplorer: {Width=100, Height=100}FileExplorer: {Width=100, Height=100}Favourites: {Width=100, Height=100}CurrentWindows: {Width=100, Height=100}RightPane: {Width=195, Height=592}Properties: {Width=100, Height=100}ultraButton1: {Width=150, Height=48}ultraButton2: {Width=150, Height=46}ultraTabControl1: {Width=660, Height=482}
At the higher DPI, the ultra buttons do scale to 200% of their size, whereas the LeftPane for example maintains its width of 195. Simon also mentioned that the split bar adorner also renders in the incorrect location for the higher DPI.
The only fix I can see for this is to make the application non dpi aware and put up with the fuzzy scaling that the Framework produces. Is this the case?
Regards
Robin
Hello Robin,
I need a little assistance in understanding what we are trying to "correct" here.
The Debug output you have provided shows that controls (not just Infragistics controls, but all design-time generated controls) are being scaled. This can be determined by simply looking at the width of the Bottom pane. The Bottom pane is docked to bottom of the form, so it will span the length of the form. Seeing this change from 622 to 1244 indicates that the form itself has been scaled. There doesn't appear to be any code in the sample performing this scaling, so it is the .NET framework doing it.
The behavior of the splitter drag indicator being rendered in the wrong location is an issue that has already been address. The fix is currently available in the latest untested bi-weekly build, and will be released in the next service release.
Thanks,
Chris
>The Debug output you have provided shows that controls (not just Infragistics controls, but all design-time generated controls) are being scaled.
The left pane and the right pane width didn't scale correctly as you can see in the output. It's a shame because, as you have observed, the rest of the controls are being scaled.
Please add that to Robin's list of DPI problems in the UltraDockManager.
With the exception of the UltraLiveTileView, none of our controls are DPI aware. As such, the options are to either allow the .NET framework to perform the scaling for you (which tends to paint the form with blurry rendering due to the scaling), or to mark the application as DPI aware, and perform the scaling manually. I'll use a bulleted list in hopes of avoiding missing an issue:
I hope this helps to clarify some of these issues.
I believe that I'm not your only customer who is buying Infragistics suite mainly for maintaining older Windows.Forms applications. Neither I believe that WPF or UWP are definitely The Way when it comes to desktop development: sure it might be, but before facing huge porting projects for very complex LOB applications, any investment must be very carefully planned. So this is why Windows.Forms is still not playing a side role in desktop development, and in this field, DPI awareness is a major theme.
Maybe we are all 'victims' of MS strategy, but when I read from Infragistics R&D that "none of our controls are DPI aware", I feel that the money spent by your Windows.Forms customers in renewing their subscriptions is wasted.
We are having the exact same issue. We have million of lines of code in Winform and we are not going to change soon.
We are doing the change to our application to make it DPI aware and so far everythign is working fine except the Infragistics controls which don't honor the DPI awarness. Very disapointing.
We may change the tool we are using though because the idea using Infragistics was to get help in these difficult situations.
Hugues