I was thinking about adding a doskey type functionality to my program. So I made a little test app with a subclassed edit control. The new edit proc is really basic, just to test the theory. Under the WM_CHAR check I test wParam for VK_RETURN where I make a call to GetWindowText, saving the text to a buffer. Then there's a call to SetWindowText with a null value for the lpString param. Then I test wParam for VK_UP, which would then use SetWindowText to restore the buffer'ed text.

Unfortuately the up arrow never triggers the ".elseif wParam==VK_UP" code. I've tested for VK_1 instead, and it works correctly.

Does anyone know what the problem could be?
Posted on 2002-08-19 18:13:30 by Will
Hey Will...

Windows is a real pain with high-level callbacks, like those of child windows i.e. edit controls. A lot of keypresses are often handeled by the parent window's DefWindowProc()... like UP is often a windows-standard signal for changing focus to another control, just like TAB. If you don't trap the message at the parent, your edit will never even see that message... very frustrating.

Another thought, VK_UP is one of the extended codes, like the function keys F1-12, meaning it does not send a WM_CHAR, only WM_KEYDOWN/UP. If you are trapping at the top level, put your code in the WM_KEYUP condition.

Hope that nailed it,
sulu
Posted on 2002-08-20 09:06:58 by mistersulu
Thanks sulu! That did the trick. It worked in the subclass proc, so unless I see some other bugish behaviour creep up I'll leave it there.

thanks again,
will
Posted on 2002-08-20 12:58:14 by Will
Will,

Sulu is right, the WM_KEYDOWN and WM_KEYUP messages are sent before WM_CHAR which filters then on the basis of characters.

You can use them to modify the default key combinations in a rich edit control by catching them in the WM_KEYDOWN or WM_KEYUP messages and discarding them and replacing them with your own key combinations.

You will find the GetAsynchKeyState API very useful here if you need to do this type of stuff.

The other thing is it is often easier to handle keys in the main message loop if you don't have a problem with their global scope as you do not miss out depending on what has the focus with your app.

Regards,

hutch@movsd.com
Posted on 2002-08-21 04:51:05 by hutch--
Thanks Hutch. :) I really don't have any other reason to subclass the edit control I guess. The only real reason why I did it was to make it easier to cut/paste the little test function into the main app. It's been a good practice for me to test functions in separate programs before adding them to the main one.

thanks,
will
Posted on 2002-08-22 10:10:27 by Will