When I send a WM_GETFONT message to a window, why don't I get a font?
A customer reported that the
WM_GETFONT message was not working. Specifically, they sent the message to a window, and they can plainly see that the window is rendering with a particular font, yet the
WM_GETFONT message returns 0. Why isn’t the window returning the correct font handle?
WM_GETFONT messages are not mandatory. A window may choose to support them, or it may choose not to, or it may even choose to support one but not the other. (Though if it supports
WM_SETFONT, it probably ought to support
For example, our scroll bar program creates a custom font for the items in the list, but it does not implement the
WM_GETFONT messages. If you try to change the font via
WM_SETFONT, nothing happens. If you ask for the font via
WM_GETFONT, you get nothing back.
A control might ignore your attempt to change the font if it already has its own notion of what font it should be using. Or maybe the control shows content in multiple fonts, so the concept of “the” font does not map well to the render model. (What would
WM_GETFONT on an HTML control return?) Or maybe the control doesn’t use GDI fonts at all. (Maybe it uses DirectWrite.)
That’s one of the reasons why the rules for the
WM_SETFONT are set up the way they are. Since there is no way to tell whether a window did anything in response to the
WM_SETFONT message, there would be no way to know whether responsibility for destroying the font should be transferred to the control or retained by the caller.
Controls that are designed to be used in dialog boxes are the ones most likely to support the
WM_SETFONT message, since that’s the message the dialog manager uses to tell each control the font specified in the dialog box template. The hope is that all of the controls will respect that font, so that the controls on the dialog box have a consistent appearance. But there’s nothing preventing a control from saying, “Screw you. I’m drawing with OCR-A and there’s nothing you can do to stop me.”