I don't even see mouse move event available for a button. It's available for the dialog though. If you can find it in the control, just call the dialogs mouse move event from within the controls mouse move (if that exists).

[EDIT]
God, I just remember how ugly MFC is. Why in the world would they even release something like that. What a monster.

See, that solution requires having a non-default class assigned to the Button or whatever other control. I want to avoid that so I can just have a single function in the dialog the control exists in. I removes a lot of pain and agony that way. Even doing a single non-default class for all the controls is a pain in the butt. Something I could hack into the dialog's header or source would be much better.

You're still losing me - not sure what you're trying to do exactly. But in essence, you already probably have what you need. Check out the definition of the BEGIN_MESSAGE_MAP macro (right-click - go to Definition, if you can) - my ATL version looks like this:

#define BEGIN_MSG_MAP(theClass) \
public: \ 
  BOOL ProcessWindowMessage(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT& lResult, DWORD dwMsgMapID = 0) \ 
  { \ 
    BOOL bHandled = TRUE; \ 
    (hWnd); \ 
    (uMsg); \ 
    (wParam); \ 
    (lParam); \ 
    (lResult); \ 
    (bHandled); \ 
    switch(dwMsgMapID) \ 
    { \ 
    case 0: 

In other words, you already have a function that is set up to handle every type of possible message that Windows will pump around. The whole reflection thing is a red herring - that's usually for when a dialog's child control is trying to notify the parent that something's going on, and you as the parent want to redirect that message back to the child for whatever reason. Generally, a child control will direct messages to the parent dialog - it has to, since the parent dialog decides what happens based on a click, a scroll, etc.

If you want the override for mouse move, you just need to add ON_WM_MOUSEMOVE to your message map...
Check out "Message Maps" and "Handlers for WM_Messages" in the MFC library reference in MSDN - it has all the info in there on all the message types & the name of the handler functions...

Wil Renczes: Thanks, that's sorta what I needed to know.

So now I know what I wanted to do is impossible, because these classes don't shove mouse move events back to the parent.

I can't do that find declare thing because it wants to build some weird stuff and I figure it's best not to what with MSVC being what it is.

And Rick, CButton derives from CWnd, so obviously it does have mousemove.

It's not at all impossible, William. Maybe I'm not understanding something entirely, though. Is it impossible or impractical for you to simply create a custom button class derived from CButton? Then it would be fairly trivial to handle the message however you need, and pass it to the parent if you so desire.

Any window can receive and handle any message that is normally sent to windows. ClassWizard, however, in its infinite wisdom, applies a message filter to CWnd-derived classes, so that it will list certain messages only for certain types of windows. Of course, you can always add the message map entries yourself, but if you want ClassWizard to be able to do it, it's fairly easy. Just go to the "Class Info" tab, and set "Message Filter" to "Window". Now the messages list in the "Message Maps" tab should have a lot more stuff in it.

Rick: come on, be fair. MFC can only be as ugly as the underlying Win32 API. ...Oh, wait.

In all honesty, though, I've been using Visual Studio 6 and MFC for Windows programming for nearly six years now, and I've found it to be more than adequate. I wouldn't use MSVC for much else besides writing Windows apps, naturally, but it gets the job done, and I suppose I'm used to it. MFC itself certainly has its quirks (a LOT of quirks), but I've always managed to get it to do what I wanted to do with relatively little hassle.

BOOL CAboutDlg::OnInitDialog()
{
    CDialog::OnInitDialog();
    SubclassDlgItem(ID_SOMECONTROL, this);

    return true;
}

That's not quite how SubclassDlgItem works. It doesn't route messages through the parent's message map, it gives them to the window procedure of the window for which SubclassDlgItem is called. In this case, you don't want to subclass your button to your dialog. This code will produce an assertion failure right away.

SubclassDlgItem simply gets the window associated with the control ID and calls SubclassWindow. CWnd::SubclassWindow tries to attach the control HWND to the CWnd object, and CWnd::Attach asserts because your dialog already has a window attached to it.

To properly use SubclassDlgItem, you should set up a class that will intercept your messages. I've dressed up the basic example from MSDN to show you what I mean:

This will dynamically subclass the button to the CMyButton object, which will then receive its messages. The CMyButton::OnMouseMove() handler will be called when the cursor moves across the button, and the coordinates (relative to the upper-left corner of the button) will be displayed as the button's caption.

No, it can't; not dynamically, anyway. If I understand what you mean correctly, the closest thing would be creating a class using multiple inheritance, deriving from both CButton and some other class. I'm not sure why you'd want to do that, though. Multiple inheritance of any sort is usually best avoided, unless you have a really compelling reason to use it.

You can't make your button an instance of a custom class in the dialog editor. Probably the easiest way is to use ClassWizard to add a member variable for your button. If you've added your custom button class using ClassWizard, you will be able to select your custom class as the type in the "Add Member Variable" dialog. Otherwise, you can just open your dialog's header file and change the variable to be an instance of your custom class instead of CButton.

Well, if you use SubclassDlgItem, there's no need to add a member variable with ClassWizard.

Likewise, if you simply use ClassWizard / member variable approach, you don't need to actually call SubclassDlgItem - the subclassing of the button is handled by DDX.

EDIT: I should probably clarify myself a bit here. The two approaches are essentially the same thing. It's just that in the latter case, ClassWizard handles the work, and uses the DDX functions instead of just calling SubclassWindow directly. (Also, when I said there's no need to add a member variable, that's not really what I meant - you do need an instance of your custom class to subclass to, of course.) I'm just not explaining myself well.

EDIT2:

Oop, I think I missed this somehow the first time I read this thread. May I ask why it is so difficult in this case to create a custom class for a button?

If you're really dead set against creating a new button class, one fairly easy hack would be to simply use the main dialog's OnMouseMove handler, and compare the cursor coordinates to the button rectangle. Honestly, though, it's better to just derive from CButton. MFC classes were meant to be used as base classes when you want to add functionality of your own!

Whoops, duh. I forgot about that little detail for some reason.