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 Simon, 

I'm a little confused. I'm looking at your screen shot and I'm having trouble understanding what you feel is wrong with it? I don't see anything here that looks incorrect. Can you explain more specifically exactly what you feel is wrong with this? I don't see any significant difference between your screen shot and mine. 

Going back and looking at your original post, you mentioned something about the font size increasing. But I don't see that here. I do see that the width of the panes is not increasing and so some of the text is cut off and you get some ellipsis (...) showing. But that's correct. That's what DPIAware means. It means that your application is aware of the DPI and adjusts. It means that the DotNetFrameowork makes NO adjustments. The width of a control on your machine is specified in pixels and it will be the same number of pixels on every machine. A machine running a higher DPI, therefore, will show that object as much smaller. It sounds like you are confused about what DPIAware means. A lot of people get it backward and think it means that it will automatically resize your controls to look good on any DPI. But that's the opposite of what it does. 

Mike,

The issue that I have is that both the UltraButton and UltraTab controls have sized themselves to accommodate for the higher DPI.

The UltraDockPanes have stayed the same width in pixels that they were designed with.  I haven't needed to write any scaling code for the buttons and tab dialog (I would say that they are DPI aware), where the UltraDockManager has not.

If you use the splitter drag bar to increase the width of the System Explorer, you will also see that the adorner is too small, and the drag line gets displayed in the wrong position.  I have attached an image to show this.

Hi Simon, 

Simon Holderness said:

The issue that I have is that both the UltraButton and UltraTab controls have sized themselves to accommodate for the higher DPI.

I don't think that is the case. It's certainly not happening on my machine. I did a test just to verify. First, I updated your sample so that the "Hello" button outputs all of the sizes of the relevant controls to the Output Window. Like so:

        private void ultraButton2_Click(object sender, EventArgs e)
        {
            foreach (var dockArea in this.ultraDockManager1.DockAreas)
            {
                Debug.WriteLine(dockArea.Size, dockArea.Key);

                Debug.Indent();
                foreach (var pane in dockArea.Panes)
                {
                    Debug.WriteLine(pane.Size, pane.Key);
                }
                Debug.Unindent();
            }

            Debug.WriteLine(this.ultraButton1.Size, this.ultraButton1.Name);
            Debug.WriteLine(this.ultraButton2.Size, this.ultraButton2.Name);
            Debug.WriteLine(this.ultraTabControl1.Size, this.ultraTabControl1.Name);

        }

I then ran the sample on a machine where the FontSize/DPI was set to 100%. Then I ran the same sample on my laptop at 200%.

The results in both cases were exactly the same for every control:

100%

BottomPane: {Width=622, Height=145}
    Log: {Width=100, Height=100}
    Debug: {Width=100, Height=100}
LeftPane: {Width=195, Height=221}
    SystemExplorer: {Width=100, Height=100}
    FileExplorer: {Width=100, Height=100}
    Favourites: {Width=100, Height=100}
    CurrentWindows: {Width=100, Height=100}
RightPane: {Width=195, Height=221}
    Properties: {Width=100, Height=100}
ultraButton1: {Width=75, Height=24}
ultraButton2: {Width=75, Height=23}
ultraTabControl1: {Width=330, Height=241}

200%
BottomPane: {Width=622, Height=145}
    Log: {Width=100, Height=100}
    Debug: {Width=100, Height=100}
LeftPane: {Width=195, Height=221}
    SystemExplorer: {Width=100, Height=100}
    FileExplorer: {Width=100, Height=100}
    Favourites: {Width=100, Height=100}
    CurrentWindows: {Width=100, Height=100}
RightPane: {Width=195, Height=221}
    Properties: {Width=100, Height=100}
ultraButton1: {Width=75, Height=24}
ultraButton2: {Width=75, Height=23}
ultraTabControl1: {Width=330, Height=241}

In fact, if you look at your screen shots, there is clearly less empty space around the tab captions when you run at a higher font size. So the size of the tabs has not changed in pixels.

As for the button, I think it's probably sheer luck that that the control already has enough empty space to fit the text when it's displayed at a higher font size.

Again, DPIAware means that the application code expects the DotNet framework to keep everything the same size - to make NO adjustments for system settings font size and to leave it entirely up to the code to adjust as needed. That's the whole purpose of that setting.

You seem to want the application to adjust without you have to do anything. The DotNet framework does this by default - or least tries to. It's often not completely successful since it takes such a broad approach.

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

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

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.

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

Hi Chris,

Thanks for the reply.

Our end goal here is to make our application DPI Aware, remain functional and look beautiful.

From other threads, I believe that your UltraDockManager is not DPI Aware and therefore does not respect the AutoScaleMode property that a Framework ContainerControl would give.  Please correct me if I am wrong.  Therefore we need to manage the scaling ourselves.

However, whilst we can do this, from the testing we have done there are still some issues:

1. The split drag indicator being rendered in the wrong location was one but you have fixed this so we look forward to the next service release.
2. The window splitter cursor used when dragging the split is not scaled at high DPI and appears smaller than expected.  Is this fixed too or can we adjust this?
3. The image in the UltraTabControl buttons that allow you to scroll between tabs also are not scaled at high DPI and appear smaller than expected.

Thanks

Robin