Custom MFC control contains another control - messages not getting through

Question

I have a custom CWnd-derived MFC control, which works like this:

1. the control has its own OnPaint, and a black background
2. clicking anywhere on the control causes an edit control to appear at that location, borderless and with black-background, so it blends in
3. the user types in this box and hits enter, the box disappears and the control's custom paint functionality renders the same text in the same position on the background.

So our control owns a CCustomEdit, when you click on the background the control is either created or moved, and made visible:

CCustomEdit::Show(Rect &rc,CCustomControl *pParent)
{
    if ( !::IsWindow( m_hWnd ) )
    {
        Create( ES_LEFT | ES_AUTOHSCROLL | WS_CHILD | ES_NOHIDESEL | ES_CENTER | ES_UPPERCASE, rc, pParent, 999 );
    }
    else
        MoveWindow( &rc );
}

The main parts actually work OK (and we're stuck with the approach). But one thing that's not working is that CCustomEdit self-registers for EN_CHANGE events and so on. When CCustomEdit is created as a normal dialog control (CEdit on the dialog template, DDX-bound to a CCustomEdit variable) these work, but within CCustomControl they are not.

CCustomEdit::PreSubclassWindow() calls SetEventmask() and is being called. And CCustomEdit's ON_CHAR handler is also being called for key-presses in the edit box, however the handlers for edit-box messages like EN_CHANGE are not.

Are there any obvious things like changing the style flags? Otherwise, why is my custom control stopping these events reaching the contained edit control?

Answer 1

I'm not sure I understand the situation, but I have a number of control that work roughly in the same way as what I think is happening and they all work, it is possible.

EN_CHANGE for the edit control is send to your CWnd-derived control. Are you reflecting the messages? Have you tried if EN_CHANGE gets to the custom control? From what you are describing, you are expecting EN_CHANGE to end up in CCustomEdit's message dispatcher macro chain automatically, but it doesn't; you need the help of the containing window. Now MFC does most of that for you in a CDialog, but if you roll your own you need to do it manually, or use the message reflection macro's.

Answer 2

I found it... somehow, my SetEventMask() was being overriden. I don't know how or where but when I added an extra call later on to test, most event handlers started getting called.

I can only assume some part of the init code in MFC is responsible.