A customer reported that the WM_GET­FONT 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_GET­FONT message returns 0. Why isn’t the window returning the correct font handle? The WM_SET­FONT and WM_GET­FONT 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_SET­FONT, it probably ought to support WM_GET­FONT.) For example, our scroll bar program creates a custom font for the items in the list, but it does not implement the WM_SET­FONT or WM_GET­FONT messages. If you try to change the font via WM_SET­FONT, nothing happens. If you ask for the font via WM_GET­FONT, 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_GET­FONT on an HTML control return?) Or maybe the control doesn’t use GDI fonts at all. (Maybe it uses Direct­Write.) That’s one of the reasons why the rules for the WM_SET­FONT are set up the way they are. Since there is no way to tell whether a window did anything in response to the WM_SET­FONT 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_SET­FONT 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.”