A customer reported that the
WM_ 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_ message returns 0. Why isn’t the window returning the correct font handle?
WM_ 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_, 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_ messages. If you try to change the font via
WM_, nothing happens. If you ask for the font via
WM_, 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_ 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_ are set up the way they are. Since there is no way to tell whether a window did anything in response to the
WM_ 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_ 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.”