Capturing The Enter Key

This is a discussion on Capturing The Enter Key within the Windows Programming forums, part of the Platform Specific Boards category; Does Anyone Know how to capture the "ENTER" key-press, so that you can process text entered into an edit control?
...

Capturing The Enter Key

Does Anyone Know how to capture the "ENTER" key-press, so that you can process text entered into an edit control?

Like a search engine. Type the search word. Press "ENTER". The program figures out the rest.

My initial guess is something like this:

In "case WM_COMMAND:" I somehow specify the control code for the "enter" key. If it was pressed, I check that there is a string to be processed in the previously empty edit control. If so, process the string, and reset the edit control to it's empty state.

Dialog? No I'm trying to capture the "enter" pressed from the users keyboard, and I want to send it to a standrd window, not a dialog box. You were right about "VK_RETURN" as being the correct lo-word code, but for some reason my system just ignores it!

You see, when I run the program, and do not "change the focus" of the window to child windows within, and press the "enter"key, works great.

When I click within one of the child windows and press enter, nothing. Yet, if I, say, minimize and then maximize the window, it works again till I click some child window!

Now then, the Parent window is "hwnd", and hwnd has no parents (such as desk-top, etc). All of the children specify "hwnd" as their parent, so...

...it doesn't make sense that changing the window focus should affect the recognition that a message has been sent to the "window in focus" since
1) All children are children of hwnd and
2)There is only one window procedure in this program -- who else could windows be sending the message to??!

Which leads me to my second question:

Since in WinMain there is only one window procedure to be associated with the WNDCLASSEX structure, how can I associate more windows procedures?! Fill another WNDCLASSEX structure?

I just don't know!

And again, since there is only one window procedure in this program, why on earth is my program not getting the VK_RETURN message when the "focus" changes? Is there some way to make sure that all messages get processed in one application message queue?

The edit control will have it's own internal window procedure, if you wish to override some aspect of it then you can get it's existing WinProc() by using GetWindowLong() using GWL_WNDPROC (you'll want to store the returned value as a WNDPROC) and use SetWindowLong() to set a new WindProc() for it.

Then create the new WinProc() that will override the default behavior of the edit control (trapping the VK_RETURN). (This is the one that you pass to SetWindowLong().) Pass all other messages from this overrided WndProc() to the default WinProc() for the edit control (that you got from the GetWindowLong() call) using CallWindowProc().

For edit controls to be able to process the enter key or VK_RETURN the style must also be ES_WANTRETURN.

Your main window should receive the message prior to child windows.

If it is the child window that has the problem, there used to be a small bug in Windows with MDI. For some reason the first child window would not receive the focus upon creation. There was an easy workaround, but this bug has probably been fixed. But, this would cause the message not to be processed. Again, this is an old bug and probably is not what's wrong.

But, if you re-write the WinProc for your window and process the message, it should work perfect.