Charles Petzold

Along with the normal degradation and death that accompanies the aging process is presbyopia — the diminishment of visual clarity at short distances. People customarily correct for presbyopia with reading glasses and by increasing the Windows display resolution to 120 DPI.

I am convinced that no WPF developer at Microsoft uses the 120 DPI resolution. How else can one explain the persistence of blatant bugs affecting the relationship between the Height, Width, ActualHeight, and ActualWidth properties when running under 120 DPI? I first came across this problem with the February CTP and brought it to the attention of someone at Microsoft who assured me it would be fixed. Yet, it's still with us in the May release.

According to the documentation, the four properties I listed all use device-independent units of 1/96th inch. The TestDeviceIndependentUnits.cs program (and here's the project file) displays the current values of ActualWidth and ActualHeight. The program initializes itself by setting Width and Height to 300. It has two buttons, one of which sets Width to ActualWidth plus 1, and the second which does the same for height.

When you run this program under a display resolution of 96 DPI, it works just as you would expect. But try it under 120 DPI and craziness breaks out. Clicking the first button causes the width of the window to increase by 96/120th unit rather than 1 unit, and — here's the really nutty part — it also causes the height of the window to increase by 25%! The second button, which sets the Height to ActualHeight plus 1, also results in an increase of window width by 25%.