| Date: | February 8, 2005 / year-entry #33 |
| Tags: | code;history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050208-00/?p=36503 |
| Comments: | 22 |
| Summary: | Once you invent a new flag you can start using it to fix errors of the past without breaking backwards compatibility. One of the errors of the past was that property sheet page dimensions were taken relative to the "MS Sans Serif" font, even if the page used some other font. DLG_SAMPLE DIALOGEX 32, 32,... |
Once you invent a new flag you can start using it to fix errors of the past without breaking backwards compatibility. One of the errors of the past was that property sheet page dimensions were taken relative to the "MS Sans Serif" font, even if the page used some other font. DLG_SAMPLE DIALOGEX 32, 32, 212, 188 CAPTION "Caption" FONT "Lucida Sans Unicode" ... This sample dialog template says that it is 212dlu wide and 188dlu tall. If the dialog template were used for a standalone dialog, those DLU values would be calculated relative to the font on the dialog, namely Lucida Sans Unicode. However, if the dialog template were used for a property sheet page, earlier versions of Windows would interpret the values 212 and 188 relative to the font of the property sheet frame (usually MS Sans Serif), not relative to the font associated with the page itself. Many people worked around this problem by giving their pages pre-adjusted sizes, so that when Windows measured the dialog against MS Sans Serif, the adjustments cancelled out.
In other words, suppose that Lucida Sans Unicode is 25% wider
than MS Sans Serif. (I'm just making up numbers.)
Then to get a 212dlu-wide dialog relative to Lucida Sans Unicode,
the dialog template would specify a width of
Since people were now relying on this behavior, it couldn't be changed. If you went in and "fixed" it, all those pre-adjusted dialogs would come out at the wrong size.
Ah, but now there is a new flag, |
Comments (22)
Comments are closed. |
What is the solution for people who want to use property sheets in a program that runs on NT and 2000 and do not want to use MS Sans Serif?
Are we still stuck doing the presizing of controls or dynamic dialog size adjustment? http://support.microsoft.com/kb/142170/
But, uh, doesn’t this break the intention that you could use DS_SHELLFONT (and, accordingly, the same resources) with older versions and later versions without breaking stuff?
So, where can we see this DS_SHELLFONT in action? I’m running XP Pro. I wonder if it is either used all over the place and I am used to it now, or it isn’t used in very many places.
", doesn’t this break the intention that you could use DS_SHELLFONT with older versions and later versions without breaking stuff?"
If you’re using a custom font, then DS_SHELLFONT buys you nothing from the font perspective, so just leave it off if you care about running on Windows 2000 or earlier.
Matt Green: All Explorer dialogs (e.g. The "Run" dialog) for example use it.
Hopefully this is not off topic.
I have a property sheet with some pages. Now all of them (sheet and pages) have DS_SHELLFONT and "MS Shell Dlg" as font. All property pages show up just fine on English XP, but, alas, my application must run on Japanese XP. It doesn’t look so good there.
What I don’t understand on this Japanese XP, all dialogs show with correct fonts, except for (this) property sheet. I don’t know which font is used there, but it is certainly different and not anti-aliased.
Is there some special magic trick, that keeps the property page from using the correct font (Tahoma) ? It is an English only application (for now).
Raymond writes: "Starting in Windows 2000, if you specify the DS_SHELLFONT dialog style for your DIALOGEX dialog template, then the dialog dimensions are taken relative to the font you specified"
I don’t understand this. According to the documentation, "Starting with Windows 2000, if you specify the Dialog Box Template Style to DS_SHELLFONT you can change the font size but you can no longer change the font face.".
It also documents that "DS_SHELLFONT has no effect if the typeface is not MS Shell Dlg."
So what’s up with this?
You’re taking the sentence out of context. The previous sentence is "The typeface member of the extended dialog box template must be set to MS Shell Dlg. otherwise this style has no effect." The second sentence has an implicit "if you intend the DS_SHELLFONT flag to have any effect" attached.
It’s like responding to, "That hat is keeping your head warm. You can’t take it off." with "Yes I can, watch me!" Yes, you can take off your hat, but then it’s not keeping you warm any more. Does that mean the person was wrong when they said "You can’t take it off"? No, because there was an implied "… if you want your head to stay warm" at the end.
So, is all of this behavior dependent on there not having been any Win95/NT4 apps that used DS_SETFONT | DS_FIXEDSYS? For example, the app used the flags together and now when they run on 2000 they get a different font and their property pages are resized? Or was there something back in the day that told developers "don’t use these flags together"?
95/NT apps would/should never have combined those flags. DS_FIXEDSYS tells the dialog to use the fixed width system font, DS_SETFONT tells it to use the font specified in the dialog resource.
"If you’re using a custom font, then DS_SHELLFONT buys you nothing from the font perspective, so just leave it off if you care about running on Windows 2000 or earlier. "
But, then the other property pages will revert to non-DS_SHELLFONT behavior, too, on >= 2000? So, my code will use Lucida Sans Unicode, but the other pages will use MS Sans Serif, not Tahoma, as there is one page in the dialog lacking DS_SHELLFONT, because it has to lack that style to be properly sized in all versions. Conclusion: Don’t use custom fonts in property sheets?
I am not the most visually observant person out there. This is why I don’t design websites any longer; I can’t really tell the difference between a good color scheme and a really bad one (ok, ok…I know magenta is out of the question).
What I’m getting at is, I’m not sure if I can tell the difference between dialogs with the DS_SHELLFONT flag and dialogs without it.
Could someone point out what exactly the difference in appearance would be?
Some screen shots would be awesome.
"Conclusion: Don’t use custom fonts in property sheets?" -> in shared property sheets – because the result is a property sheet where each page has a different font -> ugly.
boxmonkey: Just write a test program and put the two dialogs side by side.
boxmonkey: The visual difference between MS Sans Serif and Tahoma is quite subtle; in fact, I never even noticed a difference until this post series prompted me to take a look around.
Tahoma is shorter (vertically) than MS Sans Serif. As Raymond pointed out, the Start->Run dialog box correctly uses DS_SHELLFONT and thus will have (typically) Tahoma; open this up, then click Browse and very carefully compare the font of the Cancel buttons: they’re different. (The common dialogs–along with about half of the dialog boxes in Windows–don’t appear to use DS_SHELLFONT.)
Hopefully these inconsistencies can be fixed in Longhorn, but I understand that in the grand scheme of things its low priority–we don’t want features to end up being canceled because of the time spent fixing this. But it would add that extra level of polish.
Raymond: I did exactly as you suggested before I posted my question and I could not see a difference. I wasn’t sure if I did one of your steps wrong, or if I just could not tell the difference.
Jonathan: Thanks, your suggestion did it for me. I can now see that my implementation following Raymond’s steps worked perfectly.
The difference is so extremely subtle, however, that I think it’s not worth taking the time to make all my dialogs use DS_SHELLFONT.
2/8/2005 8:36 AM muro
> Now all of them (sheet and pages) have
> DS_SHELLFONT and "MS Shell Dlg" as font.
[…]
> What I don’t understand on this Japanese XP,
> all dialogs show with correct fonts, except
> for (this) property sheet. I don’t know
> which font is used there, but it is
> certainly different and not anti-aliased.
The default font is MS UI Gothic and it cannot be anti-aliased at reasonable font sizes. (At around 20 pixels or greater it can be anti-aliased but who wants to waste that much screen space?)
As for one of your pages getting a different font from your other pages, I can’t guess.
> Is there some special magic trick, that
> keeps the property page from using the
> correct font (Tahoma) ? It is an English
> only application (for now).
Cases where Tahoma would be the correct font are rare. If you are responsible for every character that gets displayed in the page, and you know that every character is displayable in Tahoma, then fine. But if you display a filename where the name comes from the user’s disk directory, or if you display an "OK" or "Cancel" or other button where a Windows library puts its words there, then Tahoma would render them unreadable. And there are programmers who do this to users too.
Norman Diamond:
> The default font is MS UI Gothic and it cannot
> be anti-aliased at reasonable font sizes. (At
> around 20 pixels or greater it can be
> anti-aliased but who wants to waste that much
> screen space?)
> As for one of your pages getting a different
> font from your other pages, I can’t guess.
I know now that the font used is the one mapped to for MS Shell Dlg. What I don’t understand is the inconsistency: On english XP, "MS Shell Dlg 2" is used, on japanese "MS Shell Dlg". This problem is only visible in property pages/sheets. English windows seems to use "MS Shell Dlg 2" everywhere.
OK, I found it.
In AfxGetPropSheetFont(…):
if ((PRIMARYLANGID(langid) == LANG_JAPANESE)
&& IsFontInstalled(_T("MS UI Gothic")))
wLang = MAKELANGID(LANG_JAPANESE, 0x3f);
WTF?! What can be the reason for this? Some compatibility issues?
It looks like I have to override something quite far from this (in my derived class) – is there some better way to have MS Shell Dlg 2?
(At
> around 20 pixels or greater it can be
> anti-aliased but who wants to waste that much
> screen space?)
My menu font is Sans Serif 10 non antialiased, and an "O" is around 12 pixel tall. I usually want bigger fonts on the screen, as I find readibility to be most important than quantity of information. So I’m one of the few programmers using Courier New 12 in Visual C++ :)
Ok, so to sum up the last three posts:
— Pre Win2k —
Font: Verdana
Flags: 0
Result: MS Sans Serif
Units: MS Sans Serif
Font: Verdana
Flags: DS_SETFONT
Result: Verdana
Units: MS Sans Serif
Font: Verdana
Flags: DS_FIXEDSYS
Result: FixedSys
Units: MS Sans Serif
Font: Verdana
Flags: DS_FIXEDSYS | DS_SETFONT
Result: Verdana
Units: MS Sans Serif
Font: MS Shell Dlg
Flags: DS_FIXEDSYS | DS_SETFONT
Result: MS Shell Dlg (MS Sans Serif)
Units: MS Shell Dlg (MS Sans Serif)
— Post Win2k (Assuming DIALOGEX) —
Font: Verdana
Flags: 0
Result: MS Sans Serif
Units: MS Sans Serif
Font: Verdana
Flags: DS_SETFONT
Result: Verdana
Units: MS Sans Serif
Font: Verdana
Flags: DS_FIXEDSYS
Result: FixedSys
Units: MS Sans Serif
Font: Verdana
Flags: DS_FIXEDSYS | DS_SETFONT (DS_SHELLFONT)
Result: Verdana
Units: Verdana
Font: MS Shell Dlg
Flags: DS_FIXEDSYS | DS_SETFONT (DS_SHELLFONT)
Result: MS Shell Dlg (Tahoma)
Units: MS Shell Dlg (Tahoma)
—
Is this correct?
Going by this table we can conclude 3 things:
* If you want to use the shell font, and you want your dialog to look good (but not the same) Pre-2k and Post-2k, use "MS Shell Dlg" with DS_SHELLFONT.
* If you want to use custom fonts, and you are making a property sheet, the only flag to use is DS_SETFONT. You’ll have to take the property sheet sizing bug into account.
* If you want to use custom fonts and you are not making a property sheet (or you don’t care about pre-2k), use your custom font with DS_SHELLFONT.
Regarding
2/8/2005 11:05 PM muro
and
2/8/2005 11:41 PM muro
[…]
> Some compatibility issues?
Wow, that code looks like it could be related to a famous incompatibility issue. Windows NT4 SP4 completely broke the handling of Japanese fonts in Word 97. Windows NT4 SP5 half-fixed it. It remains half-broken to this day in subsequent Windows systems. Windows 2000 US version had a fix applied during beta stages so Windows 2000 US works better than Windows 2000 Japanese with the same exact Japanese Word 97 and Japanese fonts. Windows 2003 Server US version did not inherit the full fix though, and it breaks differently depending on whether the Japanese MUI is installed or not. There are other possible configurations that I haven’t tested.
Windows NT4 SP4 and SP5 (and probably SP6) can be fixed by copying the MS Gothic font file from SP3, overwriting the SP4 version. This deletes the MS UI Gothic font. Of course this only a fix for Word 97, while it has the side effect of making MS UI Gothic unavailable to other applications which were not broken by the new font. Some day if I have time to waste, I’ll try the same stunt on a temporary trial installation of Windows XP.
Anyway, compatibility issues, yup, and how many of them.
Regarding
2/9/2005 1:23 AM Purplet
>> (At around 20 pixels or greater it can be
>> anti-aliased but who wants to waste that
>> much screen space?)
>
> My menu font is Sans Serif 10 non
> antialiased, and an "O" is around 12 pixel
> tall.
As far as I can tell, MS Sans Serif is not a usable substitute for MS UI Gothic. You gave an example of an Italian character but not a Chinese or Japanese character.
> So I’m one of the few programmers using
> Courier New 12 in Visual C++ :)
I do know that Courier New cannot display Japanese characters.
I saw anti-aliasing occur on MS Gothic (or P or UI versions) at around 20 pixels and larger, but who wants to waste that much screen space all the time? It is pretty obvious why anti-aliasing cannot be done at smaller sizes.
regarding
6:04 PM Norman Diamond
Well it just looks strange, that the property sheet loads the "MS UI Gothic" on japanese windows, regardless if you specify another font.
I was able to "fix" it by sending WM_SETFONT to all windows/controls in all property pages, but the code is rather ugly. And if somebody else wants to change something, good luck! :-(
If you want to easily reproduce the behaviour:
Try the following code on jap. and eng. XP:
1. Create a doc/view app.
2. create a prop.sheet with prop.pages:
CPropertySheet ps;
CPropertyPage pageSmall(IDD_PROPPAGE_SMALL);
CPropertyPage pageMedium(IDD_PROPPAGE_MEDIUM);
ps.AddPage(&pageSmall);
ps.AddPage(&pageMedium);
(define some resources for the two pages).
3. open the about box and the property sheet -> notice the different fonts.