I agree with David. I don't care where the info is stored or instanciated
so long as it's easy enough to set in the properties in the resource editor.
In article news:<E5EC0F91-BD16-41C8-9004-5BB7B5271626@microsoft.com>,
David Ching wrote:
On the contrary, there is no reason why the MFC framework can't
support saving the selected font on a per-control basis.
The extra font info can be saved in the .rc file similar to the
I wouldn't do that ... Like Mihai I like the fact that the controls you
get in an MFC dialog are system controls. I also like the fact that the
vanilla resource compiler is used to build resources, and so keep some
compatibility with other tools (for other languages and from other
However, there's no reason why the IDE shouldn't allow the programmer
to specify additional properties that can be set by wizard-generated
C++ code when the dialog is instantiated. That would only happen if the
programmer chose to override the default properties from the .rc file,
of course -- otherwise the controls will be default native control
Once the dialog is created, the MFC framework can enumerate the
child controls and call SetFont() on each of them that has an
Exactly ... but I wouldn't store the information in the .rc file.
OTOH ... a dialog is a dialog ... most of the time it would be wrong to
change the fonts of controls withing the dialog on a whim. An app's
user interface should be consistent and should conform to UI design
guidelines. If a font is to be changed it should be changed on a
system-wide basis (perhaps for accessibility reasons) not just because
the programmer thought it would be "cool" to use italic labels.
It's generally an error to want to alter control fonts individually.