When i type something on an edit control which got its background 'transparent' by returning a NULL_BRUSH as response to WM_CTLCOLOREDIT into the WindowProc, it behaves weird with some visual glitches:

case WM_CTLCOLOREDIT:
{
    SetBkMode((HDC)wParam, TRANSPARENT);
    return (LRESULT)GetStockObject(NULL_BRUSH);
}

When i minimize/restore the GUI looks like it 'repaint' the control to the correct state.

What am I missing?

CodePudding user response：

The edit control is trying to erase the wrong pixels by drawing the background colour over top of them, but now it's drawing a null brush so this doesn't actually erase the pixels and you see the leftover pixels.

You can't make a regular control transparent by making it not paint the background. That's just not a thing. Sorry.

The second time the control paints, it's not painting on top of a blank slate - it's painting on top of whatever it painted last time.

CodePudding user response：

AFAIK the only way to make the edit control appear transparent is to fake transparency by returning a brush from WM_CTLCOLOREDIT that looks like the background of the dialog. Transparent or NULL brushes are not supported.

This is trivial if the background is a single solid color. Just create a brush using