.NET + COM changed keyboard routing behavior

Question

Hi all!

I have a problem so strange that I hardly can put an adequate title to it.

In short: I have COM object written in MSVC++/MFC with a dialog derived from CDialog. On that dialog I have three child "user controls" - windows derived from plain CWnd.

When I use this COM object from a variety of places, everyhing works as I expect. But when I use it from a C# application (.exe file) the keyboard behavior is different, or shall I say broken.

And by different I mean that:

• each key pressed when any of my "user controls" has focus produces an "error beep" from somewhere, even if I try to swallow the WM_KEYDOWN message
• no WM_CHAR / OnChar is received by the "user control", although Spy++ says that one is posted
• if I put a MessageBox first in OnKeyDown and OnChar, THEN suddenly OnChar gets called AND it gets called BEFORE the MessageBox located first in OnKeyDown is displayed
• I can overcome the lack of OnChar getting called by posting a message from OnKeyDown, but I cannot figure out a way to stop the beeping

This is all CHANGED behavior compared to the COM object dialog being used from non-.NET applications.

I have found a work around which I'm not perfectly happy with, so if anyone could shed some light on this problem I'd be very happy! :-)

The work around goes like this. Instead of creating my "user controls", like this:

m_mheSpell.CreateEx(
 WS_EX_CLIENTEDGE,
 NULL,
 "",
 WS_CHILD|WS_TABSTOP|WS_VISIBLE|WS_VSCROLL,
 4,18,340,100,
 GetSafeHwnd(), (HMENU)3000 );

I change it to:

m_mheSpell.CreateEx(
 WS_EX_CLIENTEDGE,
 "Edit",  // <-- changed here
 "",
 WS_CHILD|WS_TABSTOP|WS_VISIBLE|WS_VSCROLL,
 4,18,340,100,
 GetSafeHwnd(), (HMENU)3000 );

and then I must make sure to block away keyboard, mouse and focus messages so the underlying edit control doesn't mess with me. I'm just afraid that I'll miss to block some important message and the user will find some unexpected behavior before I find it myself...

In short: "something" (related to the surrounding .NET environment) thinks that my "CWnd controls" aren't capable of doing keyboard processing and messes with me. Deriving from "Edit" makes this "something" change it's mind. All this does NOT happen when the surrounding process is, for example, a VB6 application.

Someone?

Answer 1

Ah, I can now answer my own question: WM_GETDLGCODE sigh