Who is responsible for destroying the font passed in the WM_SETFONT message?
The WM_SETFONT message tells a control which font
you would like the control to use for its text.
This message is a convention, not a rule.
For example, our
scratch program
doesn't pay attention to the
WM_SETFONT message.
If somebody sends it a WM_SETFONT,
nothing happens.
The scratch program just ignores the caller and
uses whatever font it wants.
Although supporting the WM_SETFONT message is optional,
if you do choose to support it, you would be well-served to adhere
to the following convention:
The WM_SETFONT message does not alter font ownership.
In other words,
whoever was responsible for destroying the font before the
WM_SETFONT message is sent is still responsible for
destroying it after the message is sent.
Corollary: If you tell somebody to use a specific font,
don't destroy the font while they're still using it,
because they're counting on you to keep the font valid.
Example: The dialog manager creates the dialog box font
and sends the WM_SETFONT message to each control
to tell it what font it should use.
The dialog manager keeps the font valid until the dialog box
is destroyed, at which point the font is destroyed as well.
But what font does a control use before it receives a
WM_SETFONT message?
Whatever font it wants.
Some controls have particular ideas about the font they will use
by default; the list view, for example, uses the icon label font.
In those cases, it is the control's responsibility to destroy
that default font when the control is destroyed.
This is true even
if the parent window creates another font and
sends a WM_SETFONT to change to that font.
There are now two fonts involved: the original default font
(which is the control's responsibility to destroy)
and the font set by WM_SETFONT
(which is the parent's responsibility to destroy).
Now this may all sound complicated, but remember the basic rule:
The WM_SETFONT message does not change who is responsible
for destroying a font.
Let's look at that scenario again, but take out the WM_SETFONT
message. (I've crossed it out below.)
A control creates a default font.
The parent window creates another font.
The parent window sends the WM_SETFONT message
to the control.
Now, without that crossed-out sentence, the ownership rules are
crystal clear.
The control is responsible for destroying the default font it created,
and the parent is responsible for destroying its own font.
The same principle applies to the WM_GETFONT message.
You can send WM_SETFONT and WM_GETFONT
messages all day long; it has no effect on who is responsible for
destroying the font at the end of the day.
