Archived

This topic is now archived and is closed to further replies.

WM_KEYDOWN in Dialogs

This topic is 5587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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:


    

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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites