Tabcontrol and High DPI Awareness

[Rolf Brandt]

Several of my users have most interesting problems with the tabcontrol. One of my programs uses a tabcontrol with seven tabs. Six of them work without any problem - these have just a few controls (listview and buttons) on it. One of them has about 30 textcontrols plus labels on it, about 30 buttons (virtual keyboard), etc.

These are the problems I experience:
- Buttons are scattered (They are arranged at form creation.)
- When a listbox is opened, underlying comboboxes shine through, can even be used.)
- Sometimes the text on all elements appears pale, hardly readable.

Any idea if any of these problems can be related to High DPI Awareness?

Rolf

[José Roca]

A program does not become High DPI aware just because you change the DPI setting. You have to use an appropriate manifest. Otherwise, in Vista/Windows 7 it will run virtualized. When running virtualized, Windows draws your GUI in a bitmap and then stretches it as if you were using 96 DPI. This can cause all kind of artifacts, blurry fonts, clipped UI elements, incorrect layout, pixilated bitmaps and icons, incorrect mouse coordinates, which can affect hit testing, drag and drop, and so forth.

[Rolf Brandt]

Thanks for the info, Jose.

Rolf

[José Roca]

About a year and a half ago, I was usig Windows 7 with a CRT monitor using a resolution of 600x800 and 96 DPI and all ran fine. One day, the monitor died and I bought an LCD one with high resolution. As everythig became so small that I could not read it, I increased the DPI. Great! I could read the text again. Back to programming. But soon I started to notice weird things using SED (my former editor) and other programs that were not High DPI aware. The fonts were a little fuzzy, drag and drop of files from explorer to the editor did not worked properly, if MSWORD was being used, sometimes the menu and toolbar of the editor became much bigger, etc. It was a pain to use it.  So I began to do research about it in the web and began to modify CWindow, from dealing with resolution independence to be High DPI aware, and to test it and refine it, I started to write CSED using the new CWindow. The version that I'm using now, 1.04, not yet released, has just some small changes regarding version 1.03. It is both High DPI and unicode aware, using CWindow for the main window, MDI, dialogs and all the controls and is working flawlessly with all the settings and themes available in Windows 7, and apparently also in Windows Vista and XP.

Therefore, the conclusion is that if you want to write a program that will work correctly in Windows 7 using a DPI different of 96, you have to made it High DPI aware and learn and follow the rules. If it is for your own use, do whatever you wish.

Graphics have, of course, the same problem. Therefore, Microsoft has deprecated GDI and developed new technologies such Direct2D and DirectWrite, that have more resolution, are hardware accelerated and High DPI aware. More resolution means having to draw more pixels, and GDI is too slow for it.

[Rolf Brandt]

Why do I catch myself sometimes that I dream of the good old DOS days when there was a screen of 80 x 25 characters? You could simply concentrate on the main purpose of the software!
(;-)

Rolf

[José Roca]

You won't believe it, but I have been doing maintenance work for my best selling DOS application until the past 31 of December. It has been used during about 25 years.

[Rolf Brandt]

Oh yes, I do! I also have two customers that still work with the DOS version of my taxi software. It's also about 20 years old.

Rolf