Search Form
Syndication
Administrivia

DEFAULT_GUI_FONT really stinks

Sorting it all Out
Michael Kaplan's random stuff of dubious value
Be sure to read the disclaimer here first!
MSDN Blogs > Sorting it all Out > DEFAULT_GUI_FONT really stinks

DEFAULT_GUI_FONT really stinks

28 Apr 2006 3:01 AM
  • Comments 17

You don't want to ever use DEFAULT_GUI_FONT. Just like the thread locale, AVICAP32.DLL, and SetLocaleInfo, it really stinks.

Raymond Chen talked about some of its history of this GetStockObject derived font last year when he answered the question What are SYSTEM_FONT and DEFAULT_GUI_FONT?

He even explained one of the big problems about it in international scenarios:

"...on a typical US-English machine, they map to bitmap fonts that do not support ClearType."

But beyond that, there is another big problem. The problem is that the actual font it resolves to is SKU dependent; it is not dependent on any of the various locale settings on the machine. It therefore becomes one of those "features" that keeps an MUI system with a changed system/user locale from being a 100% substitution for a localized system in testing.

And even in Vista, where the single world wide binary goal has really been largely achieved, the backcompat issues that come up with (for example) a Korean user who expects a particular legacy application's font settings to not change disallow 'fixing' this behavior. So we are stuck with this bit of cruft that will forever differentiate some particular language SKUs of what is otherwise a SWWB model system....

Don't forget that as Raymond talked a bit about, all of the GetStockObject derived fonts are no longer what the help topic claims to be -- they are not used by the system for anything, and remain only for the sake of applications that have depended on these ugly beasts.

So please stay away from DEFAULT_GUI_FONT; it stinks, truly!

 

This post brought to you by "ᇸ" (U+11f8, a.k.a. HANGUL JONGSEONG HIEUH-PIEUP)

, , ,
Comment on the blather
Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
Blog - Comment List
Comments
  • Christian Kaiser
    28 Apr 2006 4:00 AM
    Sorry, I guess it is mentioned somewhere long ago - what is the CORRECT way to get a font for user interaction then?

    MS Shell Dlg?
    MS Shell Dlg2?
    ...?

    (I mean, independent in the Windows version, starting (in my case) Win98 and NT4).

    Christian
  • Manuel
    28 Apr 2006 4:15 AM
    Hello, has straight time and looks around into English speaking Blogs in such a way.  To arrange Holle me suggestions around also German Blogs.  Unfortunately there is not as clasp-rich Blogs in Europe as English until soon and tschuess Manuel
  • 28 Apr 2006 4:25 AM
    Hi Christian -- this is a topic of an upcoming post (and for most people it is not MS Shell Dlg, as I mentioned already, in another post). :-)

    Hi Manuel -- I'm sorry, I don't know what kind of blog you are looking for? It makes giving advice on a German blog dificult....
  • Ted.
    28 Apr 2006 9:12 AM
    It could be a nice article, except for the fact that it's not true.  DEFAULT_GUI_FONT maps to MS Shell Dlg which in turn maps to Microsoft Sans Serif in any US English non-customized XP machine.

    Last time I checked Microsoft Sans Serif is Cleartype open.  

    And if DEFAULT_GUI_FONT was truly evil and support for it was somehow changed or deprecated then millions of shipping apps would break, that would be something very un-Chen.  
  • 28 Apr 2006 10:36 AM
    Hi Ted,

    I'm sorry, but you are mistaken -- especially on CJK machines, where DEFAULT_GUI_FONT is decidedly *not* MS Shell Dlg, and explicitly chosen by the SKU language.

    This is especially bad in Vista, given the independence from SKU that has otherwise been acheived.....
  • Ted.
    28 Apr 2006 12:07 PM
    Read what I said - run this on any XP US English machine (this is C++ code):

    LOGFONT logFont;
    GetObject(GetStockObject (DEFAULT_GUI_FONT),sizeof(logFont), &logFont );

    and look the results in the debugger.  
  • Ted.
    28 Apr 2006 1:06 PM
    The only point I was trying to make was that this statement: "...on a typical US-English machine, they map to bitmap fonts that do not support ClearType." is not true for DEFAULT_GUI_FONT.  It is true, I concede, for SYSTEM_FONT.   DEFAULT_GUI_FONT maps to a ClearType font on a typical US-English machine.     This one statement is all that ruins such a good article.  

    Other than that, yes, your article makes some valid points.  I do agree that DEFAULT_GUI_FONT is an unfortunate part of Windows history that we'll have to live with for a long time (as every MFC app ever built uses it for dialog box fonts on DBCS systems - see CDialogTemplate::SetSystemFont)
  • 28 Apr 2006 2:49 PM
    Ok, that makes sense. :-) 

    Of course I was just quoting that piece -- I am much more bothered about the SWWB problem and the fact that no piece of the system uses these any more even though the docs claim they still do....
  • charless
    29 Apr 2006 1:08 PM
    Michael,
       Having actually worked on a consumer program that shipped as a SWWB, I have run into this issue more than once. It seems to me that making DEFAULT_GUI_FONT really return what the documentation claims would be a good thing, in most cases. As it is now, if you needed to programatically draw a window that looked like a dialog box and you used DEFAULT_GUI_FONT to do the computations to get from dialog units to screen units. You would end up not only with the font looking wrong, but the aspect ration of the dialog wrong as well. I am sure that making such a change would cause many existing apps to differently. In some cases differnt would be bad/worse than now, but I believe in some cases it would be better/more correct than it is now.

       In any case I think the comments on Raymond's post show that the MSDN article for GetStockObject really needs to be updated to explain the issues and some sample code to do this the 'correct' way. If the behavior is not changed, it seems like it would be advisable to add a way to set what font returned. (at least for developers) e.g. a registry setting and a PowerToy to pick it.

    -charles
  • 29 Apr 2006 3:42 PM
    It is actually a very sad thing that these various solutions are tied to specific fonts. I plan on posting soon on why that is and why it probably will continue to be so....
  • George
    29 Apr 2006 6:23 PM
    So we shouldn't use MS Shell Dlg according to your other post.

    And we shouldn't use DEFAULT_GUI_FONT according to this post.

    Add me to the growing list of readers who wants to know what we should use here!
  • Sorting It All Out
    1 May 2006 10:12 AM
    I had an old friend/colleague and semi-regular reader of the blog who asked me this weekend how I could...
  • 2 May 2006 3:00 AM
    As to what to use instead of DEFAULT_GUI_FONT or MS Shell Dlg, you should be using the various fonts returned by SystemParametersInfo. Different parts of the UI can have different fonts (to illustrate, right-click on the desktop and go Properties, then change the various fonts under Appearance->Advanced).

    In .NET, you should be using the SystemFonts class to get the various fonts for the different parts of the UI. (which is essentially the same thing). It's a shame that WinForms doesn't automatically set the Form's font to SystemFonts.IconTitleFont (which is usually Tahoma) but I believe there was a backcompat issue between .NET 1.1 and .NET 2 which means they can't change it...
  • Sorting It All Out
    5 May 2006 7:47 AM
    I have talked about the notion of the language SKU specific nature of both MS Shell Dlg and of DEFAULT_GUI_FONT,...
  • Sorting It All Out
    6 Jun 2006 8:36 AM
    What do this question from flyingxu:

    I'm an MFC programmer. When I try to write some app for Chinese...
Page 1 of 2 (17 items) 12
MSDN Blogs > Sorting it all Out > DEFAULT_GUI_FONT really stinks