WM_KEYDOWN in Dialogs
Author
I''ve created a WIN32 app with a window in which a menu option calls a dialog box up. Now I want to grab a keypress from the user, (1,2,3,4, or ESCAPE) and I know a simple WM_KEYDOWN search on the message queue is not going to help me. I''ve read through a lot of vague theories, but none of them seem to work. Anyone have any hints I can try?
TIA
Triston
All the world''s a stage...and I seem to fall off quite a bit.
I didn't really understand what you want, but I'll answer what I think you're asking, sorry if it's not...
There's a function called TranslateMessage(don't remember params);
that will give you the char pressed, and not the key. To use it, you have to place this function like I did in:
in your case, the values returned you are interested are:
1->49
2->50
3->51
4->52
ESCAPE -> 27
(However, I don't understand why WM_KEYDOWN won't work, perhaps I was right when I said I didn't understand your question
)
Anyway, hope this helps you!
EDIT: Wait, I think I got what you where asking...
you are saying that the PeekMessage(&msg,NULL,0,0,PM_REMOVE) <> switch (uMsg) thing doesen't work for what you are doing, right?
That's something I have no idea about. Well, Sorry about all this stuff...
[edited by - algumacoisaqualquer on August 28, 2002 12:42:57 PM]
There's a function called TranslateMessage(don't remember params);
that will give you the char pressed, and not the key. To use it, you have to place this function like I did in:
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)) // Is There A Message Waiting? { if (msg.message==WM_QUIT) // Have We Received A Quit Message? { done=TRUE; // If So done=TRUE } else // If Not, Deal With Window Messages { TranslateMessage(&msg); // Translate The Message DispatchMessage(&msg); // Dispatch The Message } } Now, you will have to get the char being pressed, wich you can do with case WM_CHAR: case WM_CHAR: // Has A Key Been Released? { char TheKeyPressed; TheKeyPressed = wParam; text[i] = TheKeyPressed; i++; if (i == 97){i = 0;} return 0; // Jump Back } in your case, the values returned you are interested are:
1->49
2->50
3->51
4->52
ESCAPE -> 27
(However, I don't understand why WM_KEYDOWN won't work, perhaps I was right when I said I didn't understand your question
)Anyway, hope this helps you!
EDIT: Wait, I think I got what you where asking...
you are saying that the PeekMessage(&msg,NULL,0,0,PM_REMOVE) <> switch (uMsg) thing doesen't work for what you are doing, right?
That's something I have no idea about. Well, Sorry about all this stuff...
[edited by - algumacoisaqualquer on August 28, 2002 12:42:57 PM]
Author
quote:
Have you tried handling WM_KEYDOWN in your dialog procedure?
Algumacoisaqualquer(say that 10 times fast!), I guess it was a bit cryptic about what I was having problems with, but after a few hours of struggle and learning much more about subclassing a control on a dialog. I did find a way to get the kb controls and can map them to WM_KEYDOWN and WM_CHAR.
Funny thing happened on the way to these messages thou...
If I don't have any code in the WM_KEYDOWN case statement I don't get the WM_CHAR message to trigger. Yet I get the KEYDOWN message to fire twice. Any ideas?
LONG CALLBACK ButtonProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam){ switch(uMsg) { case WM_CHAR: { char upper; upper = (char)LOWORD ((LPTSTR)MAKELONG ((WORD)wParam, 0)); switch(upper) { case '1': MessageBox(NULL,"User Pressed 1", "Doh", 1); return 0; case '2': MessageBox(NULL,"User Pressed 2", "Doh", 1); return 0; default: MessageBox(NULL,"Something else", "Doh", 1); return 0; // Jump Back } } } case WM_KEYDOWN: //If I leave messagebox in I get the WM_CHAR message to fire first //then the keydown message is also processed, which makes sense, but I //only want the WM_CHAR message.... //If I comment this out...I get no WM_CHAR processed at all. MessageBox(NULL,"WM_KEYDOWN is processed.", "Doh", 1); break; default: return(CallWindowProc((WNDPROC)lpfnOldWndProc, hWnd, uMsg, wParam, lParam)); } // Call the original window procedure with the unprocessed messages return(CallWindowProc((WNDPROC)lpfnOldWndProc, hWnd, uMsg, wParam, lParam));} The WM_CHAR code works and I get the right message to appear, but only if the messagebox in the WM_KEYDOWN is also active. I thought I could get the WM_CHAR w/o the WM_KEYDOWN message?
(TIA)
-Triston
-Added source this morning as I try to hack my way through it...
All the world's a stage...and I seem to fall off quite a bit.
[edited by - Triston on August 28, 2002 12:03:52 AM]
[edited by - Triston on August 29, 2002 9:04:24 AM]
[edited by - Triston on August 29, 2002 9:07:06 AM]
Author
From MSDN:
"The information in the high-order word applies only to the most recent WM_KEYDOWN message that precedes the posting of the WM_CHAR message. "
If this is the case how come the WM_CHAR is getting processed first and then the WM_KEYDOWN?
Strange but true...
Or am I missing a key element here?
-Triston
All the world's a stage...and I seem to fall off quite a bit.
[edited by - Triston on August 29, 2002 9:13:44 AM]
"The information in the high-order word applies only to the most recent WM_KEYDOWN message that precedes the posting of the WM_CHAR message. "
If this is the case how come the WM_CHAR is getting processed first and then the WM_KEYDOWN?
Strange but true...
Or am I missing a key element here?
-Triston
All the world's a stage...and I seem to fall off quite a bit.
[edited by - Triston on August 29, 2002 9:13:44 AM]
A dialog box procedure should usually return TRUE if the message was handled, or FALSE if not. There are some exceptions noted in the documentation for DialogProc.
Having said that, I am not sure that you should be calling CallWindowProc.
Unfortunately, I don''t think that''s your problem. WM_CHAR messages come from a WM_KEYDOWN message being translated by TranslateMessage(). Apparently, the internal windows dialog procedure is not calling TranslateMessage() when it gets a WM_KEYDOWN message.
Can you make due with only the WM_KEYDOWN messages?
Having said that, I am not sure that you should be calling CallWindowProc.
Unfortunately, I don''t think that''s your problem. WM_CHAR messages come from a WM_KEYDOWN message being translated by TranslateMessage(). Apparently, the internal windows dialog procedure is not calling TranslateMessage() when it gets a WM_KEYDOWN message.
Can you make due with only the WM_KEYDOWN messages?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
