by Michael S. Kaplan, published on 2008/06/17 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/06/17/8609373.aspx
Ian Boyd asked over in the Suggestion Box:
Dialog Units.
What they were designed to do. Where they would have hopefully worked. How it is they originally did work. When they began to break down. The workaround used to try to keep them working. How they no longer work for their original purpose. Technique to try to roll your own.
If you think about, Ian has managed to pose seven inquiries without asking a single question as a question!
Quite an accomplishment, when you think about it.... :-)
Now covering all of this is almost the topic for a book chapter, so I couldn't really cover all seven topics in depth here is this one little old blog.
But I'll try to give a quick answer for each (when possible) and reserve some of the more complicated issues in each for another day.
So, here we go, with one initial question added that should likely have been there, and with each of them reworded to be questions (I am not being scientific here, these are all of the cuff and any I get into deeper I will be a bit more formal about.
The nitpickers should have a field day here!
What is a Dialog Unit?
If you take an "average character" (by convention, Win32 decided long ago that the letter x made a nice average character), a dialog unit is 1/4 of the width of that character (think TEXTMETRIC.tmAveCharWidth) and 1/8 of the height of not the average character but of the normal character height (think TEXTMETRIC.tmHeight). Obviously these two metrics will vary depending on the font you use, so the Dialog Unit is based on the specific dialog font for the Windows session.-- which is itself a choice based on both DPI settings and language.
What were Dialog Units designed to do?
In the world where the default font itself might have different sizes (which implies the text would have different sizes) and the DPI would cause more such weirdnesses, the way to make sure that by default the dialog would resize when these other factors changed was to make the size of the dialogs change when these other things did.
Where would Dialog Units have hopefully worked?
The place where they would have hopefully worked is when you wanted your dialogs to scale even as these various settings changed.
How it is that Dialog Units originally did work?
How they originally did work is the one place the still do work -- when your dialogs use regular old Win32 USER/GDI and the text in your dialogs uses the default dialog font face and size and weight. When you do all of this, then changing the language/font/DPI settings should allow the dialog to scale so that text that fit in one case will continue to fit in the other cases.
When did Dialog Units began to break down?
There are lots of changes that happened over time that caused this ideal to break down; I'll list a few here:
- Some dialogs would use other font faces, weights, and/or sizes with very different metrics from that default dialog font;
- Some dialogs would use multiple fonts, with not all of them having the same metrics as that default dialog font;
- In situations where the language changed, the size of the translated text would also change in many cases;
- Other technologies came along that used different scaling systems (e.g. pixels, twips, etc.) to avoid the confusion that the scaling and perceived lack of predictability thereof that the Dialog Unit system often led to.
Because more and more reasons for the scaling system to not work out kept happening, the system became more and more arcane appearing and less and less relevant to what people actually wanted for their dialogs.
What workaround was used to try to keep Dialog Units working?
No specific "workaround" was architected as a workaround -- these other technologies had other ways to define things and tried to solve the problem different ways. They just chugged along and tried to do their job.
How do Dialog Units no longer work for their original purpose?
These new technologies were still using GDI to create the fonts and USER to create the windows, which meant that these separate technologies occasionally affected by the good old fashioned Dialog Unit scaling -- an interesting problem for Visual Basic <= 6.0 (for example) where people would work out sizes perfectly that suddenly would not work well on another system.
What technique can one use to try to roll one's own solutions for the problems that Dialog Units were originally intended to solve?
This one I am going to hold off on for a bit because a deeper and more formal look at the consequences of all of the above issues will perhaps make Ian and others believe that as bad as the original solution may or may not have been, the things that have come later have not really distinguished themselves as much as they might have liked, and that rolling one's own solutions is likely to cause more problems rather than solve the ones that are there.
And there we go. Obviously I'll becoming back to some of these topics another day. :-)
This blog brought to you by ; (U+037e, aka GREEK QUESTION MARK)
Igor Levicki on 17 Jun 2008 10:05 PM:
Michael, there is a question I would like to ask -- why it is not possible in windows xp to change the size of system dialog font to something other than 8pt (say 9pt for example)?
I have noticed that for example menus catch the change but window text in applications and in system dialogs and message boxes does not.
Is this perhaps a consequence of dialog units?
Michael S. Kaplan on 18 Jun 2008 12:17 AM:
There are specific shell settings for some of those font faces and sizes -- in particular message boxes. In other cases the fonts are application-specified....
This is topic I will be picking up in an upcoming post, soon.