It appears as if neither WM_CHAR nor WM_KEYDOWN is generated when VK_RETURN is pressed in an edit box, which was subclassed by SetWindowSubclass function (Windows 7 here). If you wonder how to catch VK_RETURN, you can use WM_KEYUP, but...
I want my custom dialog box to:
- react to VK_RETURN pressed in an edit control, and verify form contents
- in case not all required fields are filled - to pop up a MessageBox and say "Fill all fields, please",
- then i want to dismiss that MessageBox with a VK_RETURN
- refocus on the same edit control that caused MessageBox to popup
Because somehow MessageBox closes upon WM_KEYDOWN, it would appear. Then my edit control receives WM_KEYUP upon regaining focus, processes it again, thus entering an infinite loop. It can be broken by clicking a mouse on MessageBox's OK button.
I spent 3 hours on this before i remembered about ControlSpy, which showed me WM_GETDLGCODE was being received.
I was able successfully process WM_GETDLGCODE in my edit control subclass procedure message instead of WM_KEYUP, while not getting abovementioned infinite loop. You don't return 0s when processing this message, as you would with WM_KEYUP
switch(msg){
case WM_GETDLGCODE:{
if(wParam==VK_RETURN){
VerifyDlgContent();
}elseif(wParam==VK_ESCAPE){
CancelTheDialog();
}
}
break;
}
Hope someone gets unstuck earlier than me by reading this.