Changing font in CDialog

Is it possible to change the font in a dialog resource, at run time?  If so,
where would I do this?

Changing font in CDialog

I usuaully do this, though there may be more elegant ways:

short int fRedraw = TRUE;
MyDialog()->SendMessageToDescendants(WM_SETFONT,
(WPARAM)MyFont.m_hObject,  //handle to font
MAKELONG ((WORD) fRedraw, 0),
FALSE);

And where do you do this?

And where do you do this?
------------------

Changing font in CDialog

When the "Select Font" button is clicked...  Alternately, it could be in
OnInitDialog();

Just call SetFont on the dialog or control.

Just call SetFont on the dialog or control. Make sure that CFont object is
not local. You can declare it as a member of your dialog and apply the font
in OnInitDialog or beyond.

---
Ajay

You got two good answers.But it is very likely you will have size problems.

You got two good answers.
But it is very likely you will have size problems.
The size of the dialog and the controls is given in dialog units,
that depend on the dialog font.
Once the dialog is created with a certain size, changing the font
will not resize the dialog and the controls.

What are you trying to solve?
This looks to me like a problem half-solved (you need some functionality,
you have thought of something, when half way and you got stuck in something)
My suspicion is that the solution that requiresa font change at runtime is
not a good solution.

If you explain what you are trying to achieve we might suggest something.


--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

That is a pretty perceptive observation.

That is a pretty perceptive observation.  I am in fact considering shrinking
the dialog when something like 800 X 600 resolution is detected, following
recent comments by Joe Newcomer.  Or maybe it would be easier to make a
smaller, otherwise identical, dialog for that situation.  I definitely want
the easiest solution.
------------------

Normally, the dialog will "shrink itself" at lower resolutions, until you hit

Normally, the dialog will "shrink itself" at lower resolutions, until you hit the minimum
resolution required by the font.

Now, the problem is that once the dialog is *created*, changing the font will not change
the size of the dialog.

What you would have to consider is loading the dialog template, changing the size of the
font resource in the dialog template, and essentially doing CreateDialogIndirect to create
a dialog using that as the default font.  This would probably cause it to resize.  See
CDIalog::CreateIndirect.  To make it modal, you would have to disable the parent; I'm not
sure how to do a top-level dialog indirectly without doing a  lot of research, which I
don't really have time to do today.

If confronted by the problem, I'm more likely to figure out an alternative representation
for the layout.  In the past, this has included using tabbed dialogs to hold groups of
controls (so they don't all have to be visible, and use up screen space), replacing groups
of radio buttons with dropdown lists, using checklistboxes instead of arrays of check
boxes, and so on.  I've also created scrolling controls when that seems appropriate, that
is, the entire control set scrolls.

Note that if you do the resizing, and use a smaller font, people like me will have serious
problems reading the contents.  Never forget the "trifocal group" in doing design.  And
don't forget the people who have selected "large font" for their default system font,
because they need the larger font to be able to read the material at all.
joe


Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

I decided the best and simplest (by far) approach was to reduce the font (and

I decided the best and simplest (by far) approach was to reduce the font
(and thus the dialog size) in the editor and maintain a happy compromise for
all resolutions.  The comments I've received here helped me greatly.  Thank
you very much!
--------------

Agree.

Agree.
As a rule of thumb, if a dialog does not fit in 800x600 then it has
usability problems (more problematic than size).



--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

I found one of the biggest challenges for me when finally learning to

I found one of the biggest challenges for me when finally learning to
the old days we did things like:

Name: [ Edit control]
City: [ Edit control]
etc.

Whereas now I mostly do:

Name:
[Edit Control]

City:
[Edit Control]

Leaving the control with the text as wide as possible to accept various
languages that may take up more space than my own.  In our written forms we
are so used to seeing it done the first way that this change was difficult
at first, but now I'm so used to the idea the old way looks strangely
crowded.  I think most of the work of setting up a localizable application
is adopting habits that make the formatting easier after translations are
done.  I'd also rather user sub-dialogs for not-often-used settings than
have one large dialog that contains them all.

Tom

Changing font in CDialog

Some good guidelines here:
http://www.microsoft.com/globaldev/getwr/steps/wrg_uiloc.mspx


For localization it is indeed easyer to use
Label:
[ field ]
than
Label: [ field ]

But truth is that there are also disadvantages: the dialogs become tall
and narrow. Not a good use of the screen space which is more wide that tall.


On the othere side, usualy a dialog that has problems in 800x600
resolution has ussability problems in English (and in all other languages)
Nothing to do with localization.
It probably has too many controls, which makes it too complex.


--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

I've found that if there are too many controls, the problem should be

I've found that if there are too many controls, the problem should be rethought.  Tabbed
dialogs work nicely for handling too many controls.  I will sometimes have a mix of
controls which are common and controls which are in tabs (e.g., my Locale Explorer). Using
droplists instead of radio buttons, or checklist boxes instead of large arrays of check
boxes, also work.  Nested dialogs (dialogs calling dialogs) on the other hand is almost
always a bad idea.  I once reduced a system which had 39 dialog templates which could nest
as deeply as five (no, I didn't write it) to a single tabbed dialog with no modal dialogs
at all (and I have wondered why concepts like CFileDialog, CColorDialog, etc. are not
actually done by ActiveX controls that are embedded in dialogs, so we can put the ActiveX
controls on our own tabbed dialogs and never, ever have a modal dialog at all!
joe


Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm