The problem is quite straightforward:
In any of the window procedures I have, I never receive WM_CHAR.
WM_GETDLGCODE returns DLGC_WANTCHARS.
IsDialogMessage reports its state as Message Processed, while WM_KEYUP and WM_KEYDOWN are sent.
(It never returns 0).
Commenting IsDialogMessage allows WM_CHAR to be sent to my procedure.
Spy++ reports WM_CHARs to be sent to my process, but I never ever see one while IsDialogMessage is "active".
Beep(600, 200); - put that in your case WM_CHAR:, if it causes a beep then you are receiving the message and somehow not processing it correctly.
If you don't hear a beep when pressing a key then go back and make sure that all of your message cases either return 0, or break;
Sometimes not doing so can cause strange problems.
If that doesn't fix things then post some code so we can review it.
When you refer to your window procedures, do you mean DialogProcs for modeless dialogs?
And are you talking about these DialogProcs receiving the WM_CHAR message?
If so, the problem with dialogs is that the dialog itself is never in focus (unless you create a dialog with no controls). So the WM_CHAR message will be processed by the window proceedure for which ever of the controls currently has the focus, not the dialog proceedure.
To route the WM_CHAR to your dialog proc you will have to either:
1. subclass the dialog controls so they send the message on to their parent dialog
2. customize the message loop so it sends WM_CHAR to the dialog before (probably?) passing it to IsDialogMessage for standard processing.
No, I mean WindowProc.
But, should I use IsDialogMessage for WindowProc's?
@Newbieg I'm sure I checked carefully, I've been checking and logging messages in every way, both from the main loop and in the window proc.
(I use PeekMessage, but IsDialogMessage is also for MSG's retrieved from PeekMessage)
I have no child windows.
My temporary fix is to check if I have child windows before calling IsDialogMessage.
There is no general way to identify if a window is a dialog (a dialog is a type of window, not something distinct.)
You can obtain the class name for a window using GetClassName and check to see if it's the system dialog class, #32770 (it's an atom rather than an actual name), but this won't work with custom dialog classes, even if the class is just a re-registration of the system class (e.g.
How to provide your own Window class name for an MFC dialog box http://support.microsoft.com/kb/251059 )
If you use GetClassInfo, or GetClassInfoEx, to get hold of the address of the WndProc for the system dialog class, you could then use GetWindowLongPtr with GWLP_WNDPROC to obtain the address of the WndProc for a given window and see if its the same as the one for the dialog class. But this will fail it the dialog has been subclassed.
As the name of the class is unchanged by subclassing, GetClassName will allow you to spot a regular dialog which has been subclassed. But a re-registered and subclassed dialog is probably impossible to identify.