Okay, I found the answer in comp.os.ms-windows.programmer.win32
For archival purposes here is the solution. You have to trap WM_GETDLGCODE in the subclassed edit procedure and return DLGC_WANTALLKEYS. Here is the code from my subclassed edit procedure and the reason given from the news group:
Code:
LRESULT CALLBACK NewEditProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
case WM_KEYDOWN:
if (wParam == VK_RETURN)
{
MessageBox (hWnd, TEXT ("Got it!"), TEXT ("NewEditProc"), MB_OK);
return 0;
}
case WM_GETDLGCODE: // *** SEE NOTE BELOW ***
return DLGC_WANTALLKEYS;
}
return CallWindowProc (g_OldDlgProc, hWnd, msg, wParam, lParam);
}
/******
NOTE:
> Thanks John for the save. The multiline style does allow the return to
be
> trapped. So what happens to the VK_RETURN keystroke is a single line
edit
> box? Where is it handled?
The dialog box eats it. See WM_GETDLGCODE message - the dialog sends it
to the control having focus when it gets a keyboard message for certain
special keys, such as Tab, Return and Arrows. If the control does not
express interest in those messages, dialog box does not forward them to
the control but instead implements standard behavior (e.g. when Return
is pressed, it "pushes" the default button).
Multiline edit control returns DLGC_WANTALLKEYS flag in response to
WM_GETDLGCODE, single-line edit control does not. In your subclassing
window proc, you can handle WM_GETDLGCODE and set DLGC_WANTALLKEYS flag
regardless of whether the underlying control is a single-line or
multiline. Then you'll always get your Return.
--
With best wishes,
Igor Tandetnik
*****/