WM_CHAR never received?

[S G H]

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".

[newbieg]

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.

[andywestken]

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
or
2. customize the message loop so it sends WM_CHAR to the dialog before (probably?) passing it to IsDialogMessage for standard processing.

Andy

[S G H]

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.

[andywestken]

IsDialogMessage for WindowProc's?

No. It's intended for modeless dialog.

You should not usually call it on the main window handle, unless you're implementing a window which hosts controls like a dialog. Then the comments about focus will hold as for a regular dialog.

Andy

[S G H]

Ok then, I guess it's solved now.
Marking as solved, but if anybody knows how to see if a HWND is a Dialog or a Window, it could be helpful.

[andywestken]

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.

Andy

[S G H]

I hope GetWindowLongPtr with DWL_DLGPROC always returns a failed state, I think I'll rely on that.

[andywestken]

I don't think you can.

GetWindowLongPtr works with an index of 0 "to the number of bytes of extra window memory, minus the size of an integer." (the extra memory being whatever you specified when you registered your class.)

DWL_DLGPROC (for use with GetWindowLong) and its modern equivalent DWLP_DLGPROC (for use with GetWindowLongPtr) are defined as:

#define DWL_MSGRESULT 0
#define DWL_DLGPROC 4
#define DWL_USER 8

#define DWLP_MSGRESULT 0
#define DWLP_DLGPROC DWLP_MSGRESULT + sizeof(LRESULT)
#define DWLP_USER DWLP_DLGPROC + sizeof(DLGPROC)

so they're in the range available for normal use (unlike the negative, system reserved values: GWLP_WNDPROC = -4, GWL_STYLE = -15, etc.)

So it is quite possible for some or other window class to be storing something at offset 4 which is nothing to do with a dialog proc.

Andy