Hi.

Is it possible to change the background color and font
color of a CEditView window? Please explain.

Thanks,
Kuphryn

You can control the background color by handling the WM_CTLCOLOR message
in the control's parent window. See the example in OnCtlColor.

You can control the font by calling the control's SetFont function.  See
"Correct Use of the SetFont() Function in MFC" in the KB article Q85518
for an example.

--
Scott McPhillips [VC++ MVP]

Hi!

Yes, use the ClassWizard to add a handler for the reflected (=WM_CTLCOLOR) message to your CEditView
derived class. Add a CBrush member variable to your CEditView derived class as well, and call its
CreateSolidBrush member function once per instance. Then in your CtlColor handler, call the CDC*
argument's SetBkColor and SetTextColor member functions, and return the member CBrush.

--
Jeff Partch [MVP]

Thanks.  I tried that approach; however, the CEditView
remains does not change color and text color.  Here is
the exact code I used.

-----
HBRUSH CMyEditView::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT
nCtlColor)
{
   pDC->SetBkColor(RGB(28, 217, 18));
   pDC->SetTextColor(RGB(18, 217, 32));
   HBRUSH hbr = CreateSolidBrush(RGB(255,255,255));
   return hbr;

-----

Kuphryn

That's a handler for the non-reflected WM_CTLCOLOR message, you want the reflected version
(=WM_CTLCOLOR). The message-map macro goes like this...

   ON_WM_CTLCOLOR_REFLECT()

...and the handler is prototyped like...

    HBRUSH CSomeEditView::CtlColor(CDC* pDC, UINT nCtlColor);

Also, you do not want to create the HBRUSH over-and-over again in the handler. Use a CBrush member
variable and CreateSolidBrush it once per class instance. If you use a member CBrush, you don't have
to worry about calling DeleteObject for it as the destructor will take care of it for you. And you
can return it directly as it has an operator HBRUSH which will be invoked automatically.

--
Jeff Partch [MVP]

Oh.  Nice!!!

Everything works great.  I have question additional
questions.

First, what is the difference between a normal message
WM_CTLCOLOR and a "reflected" version =WM_CTLCOLOR?  I
have always wondered about the "=" prefix.

Secondly, I am using a CEditView.  The technique you
mentioned does work, which I am very happy, this is one
annoying problem.  It seems =WM_CTLCOLOR only changes the
area of the view where there are texts and where the
cursor is located.  For example:

// imagine this is what my CEditView looks like
// imagine I want the background to be green
-----
testing // green area
1       // green area
2       // green area
        // green area
3       // green area
        // white area
        // white area
        // white area
        // white area
-----

I am not sure how to overcome something like that.

Kuphryn

A long time ago, before proper programming techniques were well-understood, Microsoft
decreed that the parent of a control would receive a WM_CTLCOLOR message. This was, of
course, remarkably silly, since there is no sensible way a parent of a control would know
anything about how the control wanted things painted. The result was some of the
worst-structured programs ever written. The same thing applied to WM_MEASUREITEM,
WM_DRAWITEM, and WM_COMPAREITEM, among may other messages. MFC fixes this disaster by
detecting WM_CTLCOLOR and other such messages, and routing them to the child class, where
they should be processed. By subclassing the control, you put the knowledge about how it
should be painted, compared, etc. down in the control, where it belongs. Strange thing was
that I had discovered this technique years before, and would subclass a control and add a
WM_CTLCOLOR, WM_DRAWITEM, WM_MEASUREITEM, and WM_COMPAREITEM handler to my subclass. I
would then program the mainframe to SendMessage these messages to the control whose handle
appeared in the message. Felt smug when I discovered MFC was doing the same thing.

Note that the =WM_CTLCOLOR and WM_CTLCOLOR handlers both do the same thing; you are
setting the background color FOR THE CHARACTER CELLS ONLY and not for the entire control.
You need to add WM_ERASEBKGND to erase anything outside the character cells. There are
potential problems with this as WM_ERASEBKGND can use a broader set of colors than the
SetBkColor any time you are running on less than a 24-bit-color display, so you will get
ugly mismatches on paletted displays unless you are very, very clever.

You might want to look at my "validating edit control" on my MVP Tips site for some more
insight on how to handle this, including the need to occasionally invalidate the entire
control to cause the proper updating.
                        joe

Joseph M. Newcomer [MVP]

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

Thanks.  You mentioned your website.  Can you post a link
to your website?

Kuphryn

Hi!

I think you must have a problem with the HBRUSH you return. Here's an example that paints the
control with yellow text on a green background...

    HBRUSH CNg052602View::CtlColor(CDC* pDC, UINT nCtlColor)
    {
        if (NULL == m_brushBkgnd.m_hObject)
            m_brushBkgnd.CreateSolidBrush(RGB(0,255,0));

        if (m_brushBkgnd.m_hObject)
        {
            pDC->SetTextColor(RGB(255,255,0));
            pDC->SetBkColor(RGB(0,255,0));
            return m_brushBkgnd;
        }
        return NULL;
    }

--
Jeff Partch [MVP]

See my sig block.
                joe

Joseph M. Newcomer [MVP]

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