> Hi,

> I want to make the font of a dialog control monospaced. The control is
> derived from CEdit as a multiline edit box.
> The problem is to display spaces in the text with the same with as the
> other characters in the text. The system font is proportional and not
> monospaced. I don't want to select a different font type for that.
> Any help is appreciated. Thanks.

> Udo Gerber
> EDV & Astro Service

> Internet: http://www.lichterleben.de/

> In OnInitDialog() use SetFont on the control to set its font. The font
> you use must outlive the function -- make it a member variable of the
> dialog.

> ANSI_FIXED_FONT is a stock font which you might try.

> m_font.CreateStockObject(ANSI_FIXED_FONT);
> GetDlgItem(IDC_MYEDIT)->SetFont(&m_font);

> HTH,

> David Wilkinson

> ======================

>Unfortunately I'm not quite familiar using GDI objects like fonts, etc. - so
>what steps are necessary before I can use the CreateStockObject() member on
>m_font? Let's assume a

>    CFont    m_font = new CFont();

>The docs say I have to use CreateFont() or somesuch before I can use m_font.
>At that step I don't know how to continue. Next question is: Can I
>gracefully delete this font like that:

>    CMyDlg::~CMyDlg()
>    {
>        if (m_font) delete m_font;
>    }

>I just want to be sure that windows does not loose its GDI ressources.

>Regards,
>Udo

>> Udo:

>> In OnInitDialog() use SetFont on the control to set its font. The font
>> you use must outlive the function -- make it a member variable of the
>> dialog.

>> ANSI_FIXED_FONT is a stock font which you might try.

>> m_font.CreateStockObject(ANSI_FIXED_FONT);
>> GetDlgItem(IDC_MYEDIT)->SetFont(&m_font);

>> HTH,

>> David Wilkinson

>> ======================

> (note that m_ is normally used for member variables of a class, so it
> is impossible to write the initialized declaration you show. If you
> use m_ for objects that are not class members, you will confuse anyone
> who expects you are using it in a fashion consistent with established
> practice. I avoid this by never using m_ except for values which are
> explicitly set by a parent window).
>                                 joe

>In my real code I'm using CFont* m_pFont as this is a member of the class I
>derived from CEdit, so I think it should be in the naming conventions. I did not
>mention that in my previous posting.
>What I'm now confusing about is the CGdiObject::Detach() below. The docs are not
>quite verbose, so I'm not sure when or if I *must* call it. In your example below
>you detach the font immediately after selecting it. Is that correct? Can the
>dialog really use the font after it was detached?

>Thanks,
>Udo

>> CreateStockObject creates a font if you give it a font code. For
>> example, you can do
>>         CFont font;
>>              font.CreateStockObject(ANSI_FIXED_FONT);
>>         c_MyEdit.SelectFont(&font);
>>         font.Detach();
>> which works just fine. If you don't want the ANSI_FIXED_FONT which is
>> actually sort of large, you can provide the user with the option of
>> selecting a font by specifiying, for the CFontDialog, the flag that
>> restricts the choices to fixed fonts.

>> (note that m_ is normally used for member variables of a class, so it
>> is impossible to write the initialized declaration you show. If you
>> use m_ for objects that are not class members, you will confuse anyone
>> who expects you are using it in a fashion consistent with established
>> practice. I avoid this by never using m_ except for values which are
>> explicitly set by a parent window).
>>                                 joe

> If you had done as your example showed with a CFont as a local
> variable you need the Detach(). If you are, as you now indicate, using
> it as a member variable, the Detach would be incorrect. Note that once
> the SetFont is done, the CFont object is essentially irrelevant, and
> is just taking up space, which is why I usually set a font by doing
> (in, for example, a subclassed Edit control)
>     LOGFONT lf;
>     ... set up values for lf here...
>     CFont f;
>     f.CreateFontIndirect(&lf);
>     SetFont(&f);
>     f.Detach();

> since there is no reason to keep a CFont object around at all.
> However, if I didn't do the Detach, the destructor for CFont would do
> a DeleteObject on the HFONT, which *would* cause a problem.

> The point is that once SetFont has delivered the HFONT handle of the
> CFont to the HWND, the CFont becomes irrelevant. Its only reason for
> existence was to provide an HFONT to ::SetFont(HWND, HFONT). Once that
> is done, it can be discarded. But "delete m_font" or the implicit
> destructor in my example above both then call ::DeleteObject on the
> underlying HFONT, so when the control goes to use it, the HFONT is
> bogus and is ignored. By using Detach, you break the association
> between the HFONT and the CFont, allowing a destructor to occur
> without deleting the underlying HFONT.

> You can read about attach/detach in the essay on my MVP Tips site.
>                                 joe

> On Sun, 16 Apr 2000 04:20:09 +0200, Udo Gerber

> >Joe:

> >In my real code I'm using CFont* m_pFont as this is a member of the class I
> >derived from CEdit, so I think it should be in the naming conventions. I did not
> >mention that in my previous posting.
> >What I'm now confusing about is the CGdiObject::Detach() below. The docs are not
> >quite verbose, so I'm not sure when or if I *must* call it. In your example below
> >you detach the font immediately after selecting it. Is that correct? Can the
> >dialog really use the font after it was detached?

> >Thanks,
> >Udo

> >> CreateStockObject creates a font if you give it a font code. For
> >> example, you can do
> >>         CFont font;
> >>              font.CreateStockObject(ANSI_FIXED_FONT);
> >>         c_MyEdit.SelectFont(&font);
> >>         font.Detach();
> >> which works just fine. If you don't want the ANSI_FIXED_FONT which is
> >> actually sort of large, you can provide the user with the option of
> >> selecting a font by specifiying, for the CFontDialog, the flag that
> >> restricts the choices to fixed fonts.

> >> (note that m_ is normally used for member variables of a class, so it
> >> is impossible to write the initialized declaration you show. If you
> >> use m_ for objects that are not class members, you will confuse anyone
> >> who expects you are using it in a fashion consistent with established
> >> practice. I avoid this by never using m_ except for values which are
> >> explicitly set by a parent window).
> >>                                 joe

> Joseph M. Newcomer [MVP]

> Web: http://www3.pgh.net/~newcomer
> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

> since there is no reason to keep a CFont object around at all. However, if I
> didn't do the Detach, the destructor for CFont would do a DeleteObject on
> the HFONT, which *would* cause a problem.

> The point is that once SetFont has delivered the HFONT handle of the CFont
> to the HWND, the CFont becomes irrelevant. Its only reason for existence was
> to provide an HFONT to ::SetFont(HWND, HFONT). Once that is done, it can be
> discarded. But "delete m_font" or the implicit destructor in my example
> above both then call ::DeleteObject on the underlying HFONT, so when the
> control goes to use it, the HFONT is bogus and is ignored. By using Detach,
> you break the association between the HFONT and the CFont, allowing a
> destructor to occur without deleting the underlying HFONT.

> You can read about attach/detach in the essay on my MVP Tips site.

>OK, but if you do it this way:

>    LOGFONT lf;
>    ... set up values for lf here...
>    CFont f;
>    f.CreateFontIndirect(&lf);
>    SetFont(&f);
>    f.Detach();

>the ::DeleteObject() isn't going to get called on the HFONT handle,
>unless you use GetFont() to retrieve it and do it yourself. Wouldn't
>this be a leak?

>If I do it the MFC way with a CFont member variable, then I can be sure
>that the HFONT is going to be around while the control needs it, and
>that it will be deleted by the destructor when it is no longer needed.

>David Wilkinson

>=====================

>> If you had done as your example showed with a CFont as a local
>> variable you need the Detach(). If you are, as you now indicate, using
>> it as a member variable, the Detach would be incorrect. Note that once
>> the SetFont is done, the CFont object is essentially irrelevant, and
>> is just taking up space, which is why I usually set a font by doing
>> (in, for example, a subclassed Edit control)
>>     LOGFONT lf;
>>     ... set up values for lf here...
>>     CFont f;
>>     f.CreateFontIndirect(&lf);
>>     SetFont(&f);
>>     f.Detach();

>> since there is no reason to keep a CFont object around at all.
>> However, if I didn't do the Detach, the destructor for CFont would do
>> a DeleteObject on the HFONT, which *would* cause a problem.

>> The point is that once SetFont has delivered the HFONT handle of the
>> CFont to the HWND, the CFont becomes irrelevant. Its only reason for
>> existence was to provide an HFONT to ::SetFont(HWND, HFONT). Once that
>> is done, it can be discarded. But "delete m_font" or the implicit
>> destructor in my example above both then call ::DeleteObject on the
>> underlying HFONT, so when the control goes to use it, the HFONT is
>> bogus and is ignored. By using Detach, you break the association
>> between the HFONT and the CFont, allowing a destructor to occur
>> without deleting the underlying HFONT.

>> You can read about attach/detach in the essay on my MVP Tips site.
>>                                 joe

>> On Sun, 16 Apr 2000 04:20:09 +0200, Udo Gerber

>> >Joe:

>> >In my real code I'm using CFont* m_pFont as this is a member of the class I
>> >derived from CEdit, so I think it should be in the naming conventions. I did not
>> >mention that in my previous posting.
>> >What I'm now confusing about is the CGdiObject::Detach() below. The docs are not
>> >quite verbose, so I'm not sure when or if I *must* call it. In your example below
>> >you detach the font immediately after selecting it. Is that correct? Can the
>> >dialog really use the font after it was detached?

>> >Thanks,
>> >Udo

>> >> CreateStockObject creates a font if you give it a font code. For
>> >> example, you can do
>> >>         CFont font;
>> >>              font.CreateStockObject(ANSI_FIXED_FONT);
>> >>         c_MyEdit.SelectFont(&font);
>> >>         font.Detach();
>> >> which works just fine. If you don't want the ANSI_FIXED_FONT which is
>> >> actually sort of large, you can provide the user with the option of
>> >> selecting a font by specifiying, for the CFontDialog, the flag that
>> >> restricts the choices to fixed fonts.

>> >> (note that m_ is normally used for member variables of a class, so it
>> >> is impossible to write the initialized declaration you show. If you
>> >> use m_ for objects that are not class members, you will confuse anyone
>> >> who expects you are using it in a fashion consistent with established
>> >> practice. I avoid this by never using m_ except for values which are
>> >> explicitly set by a parent window).
>> >>                                 joe

>> Joseph M. Newcomer [MVP]

>> Web: http://www3.pgh.net/~newcomer
>> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm