Jump to content
  • Advertisement

Archived

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

Triston

WM_KEYDOWN in Dialogs

This topic is 5895 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
Advertisement
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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!