Holy cow, I wrote a book!
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,
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 WM_GETFONT.)
For example, our
scroll bar program
creates a custom font for the items in the list,
but it does not implement the
If you try to change the font via
WM_SETFONT, nothing happens.
If you ask for the font via
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
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,
I'm drawing with OCR-A and there's nothing you can do to stop me."