-
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.
Am I close?
And does anyone know this key-code( and hopefully others )?!
Thanks in advance!
-
try this:
case WM_COMMAND:
switch(LOWORD(wParam))
{
case VK_RETURN:
MessageBox(hwnd, "MOO!", "MOO!", MB_OK);
break;
}
return 0;
-
Thanks, but it didn't work...
-
well is that button set as the default button for your dialog? I think it's WS_DEFPUSHBUTTON as the style to do that...
-
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!
-
Code:
case WM_KEYUP:
switch(wParam)
{
case VK_RETURN:
MessageBox(0, "Return Key Pushed", "Hey You", 0);
break;
}
break;
-
Thank you! That did work!
But one problem remains....
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?
Any input apreciated here.:)
-
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.
I'm not sure I understand the exact structure of your program.
-
o.k.
I did this, Bubba, in the CreateWindowEx() function for the edit box, I gave it this style:
WS_CHILD | WS_VISIBLE | ES_WANTRETURN
Still nothing, though.
So unless I mistook your meaning of "style", I will have to work on GetWindowLong and SetWindowLong that zen suggested...
-
Have you also included the style ES_MULTILINE ?
-
I did now!
But it still doesn't work!
Ok.Ok. Can you explain a little more, using GetWindowLong and SetWindowLong?
First, do I need to create another WNDCLASSEX structure in order to give each button a window procedure?
-
hmm, I'm not sure why that doesn't work. If you want to try and override the edit control procedure then you'll have to do something like this -
Code:
//Global WNDPROC storage
WNDPROC DefEditProc;
//Subclassing Procedure
LRESULT CALLBACK EditProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam)
{
switch(message)
{
///.....
///Intercept messages to override
///
default: //Send all messages not processed to default edit proc
return CallWindowProc(DefEditProc,hWnd,message,
wParam,lParam);
}
}
//Main Window Procedure
LRESULT CALLBACK WinProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam)
{
//variables etc
static HWND hWndEdit;
switch(message)
{
case WM_CREATE:
{
//Create edit box as normal storing handle in hWndEdit
//GetWindowLong and SetWindowLong calls can be merged
//as SetWindowLong returns old procedure
DefEditProc = (WNDPROC)GetWindowLong(hWndEdit,GWL_WNDPROC);
SetWindowLong(hWndEdit,GWL_WNDPROC,
(LONG)EditProc);
//rest of message handler
return 0;
}
//rest of message handlers
}
}
-
Cool, I will try that out right now!
-
Thank You!!!
Anyway, although I don't quite understand what I added to my code, I will study it and hopefully figure it out!
Thank you for helping me out!
One last thing though, Now the edit control will not let me type in it!
It WILL let me delete the default text in that control, but that's it!
Any Ideas?