Paint problem when handling WM_CTLCOLOREDIT

Question

I have an non read only edit control for which I need to change colors so I handle WM_CTLCOLOREDIT. It works well when I am typing continuously but the problem is when I hit backspace or delete or even start typing from the middle of an existing text, the display is all junked up. That remains untill I cause a repaint by resizing the parent etc. How to fix this?

Edit: Some detail. The problem seems only when the background color is set and not when just the text color is set. The code looks like this

ON_MESSAGE(WM_CTLCOLOREDIT, OnEditColor)

LRESULT CMyWindow::OnEditColor(WPARAM wp, LPARAM lp)
{
    HDC hdc = (HDC)wp;
    HWND hwnd = (HWND)lp;
    if(hwnd == m_edit.GetSafeHwnd())
    {
    //  SetBkMode(hdc, TRANSPARENT);
        MyControlInfo*pcti;// accessed from somewhere
        SetTextColor(hdc, pcti->theme.clrText);
    //  return (LRESULT)pcti->brush.GetSafeHandle();
    }
    return 0;
}

Thanks

Aren't we just supposed to return the brush? Won't the system do the painting? I thought we paint ourselves only in ownerdrawn controls. — joseph, Mar 31 '11 at 15:28
Oh, but even when I return a brush, the backspace delete etc won't paint properly. I tried returning a brush always. Anyway, since I have just one edit control, the zero return mustn't affect. — joseph, Mar 31 '11 at 15:37

score 1 · Answer 1 · answered Mar 31 '11 at 15:45

I rather doubt that this is caused by this code. It is the kind of problem you get when you try to subclass the edit control and override painting. Windows version 2 having to run on a 386SUX and 20 years of appcompat prevented Microsoft from fixing this control so it only draws itself in the WM_PAINT message handler. It indeed draws directly to the screen when you backspace. There's no workaround for it.

Same comment applies as in your previous question, use a real edit control.

score 1 · Answer 2 · answered Mar 31 '11 at 15:46

1

You should set a background color with SetBkColor (And don't use SetBkMode) and return a valid brush. (You don't know how the control does its painting, it is free to use ExtTextOut with ETO_OPAQUE etc)

answered Mar 31 '11 at 15:46

Anders

97,548
12
110
164

score 0 · Answer 3 · answered Mar 31 '11 at 16:30

http://msdn.microsoft.com/en-us/library/bb761691(v=vs.85).aspx

Return Value

If an application processes this message, it must return the handle of a brush. The system uses the brush to paint the background of the edit control.

So try something like:

return static_cast<LRESULT>(::GetSysColorBrush(COLOR_WINDOW));

Paint problem when handling WM_CTLCOLOREDIT

3 Answers3