Thread: WM_CHAR problems

I am working on a simple text-editor app and want to display the number of lines in the file (editbox) in the status bar. I try to process the WM_CHAR, WM_KEYUP or WM_KEYDOWN message, but they never get executed when I press a key. I have got this just before WM_COMMAND:

Code:

    case WM_CHAR:
        if ((wParam = (WPARAM) CharUpper ((TCHAR *) wParam)) == VK_RETURN) GetLines(hwnd);
        break;

Where GetLines works perfectly:

Code:

void GetLines(HWND hwnd)
{
	HWND hEdit = GetDlgItem(hwnd, IDC_MAIN_EDIT);
	SendDlgItemMessage(hwnd, IDC_MAIN_STATUS, SB_SETTEXT, 1, (LPARAM)szLines);
}

I am trying to run GetLines whenever the enter key is pressed, but no matter how many times I press a key, the (UINT) msg never equals WM_CHAR or WM_KEYUP or WM_KEYDOWN. Any ideas?

No, I am not subclassing the edit box, just creating it using CreateWindow, setting the font and leaving it. I am using the default WndProc for handling all the messages. I have not researched subclassing yet and would not have done it intentionally.

Thanks, i'll work on that. Two more things, 1. Is the sizing for the edit box done in WM_SIZE for the new WndProc? and 2. How do I reference the edit control now. e.g. this doesn't seem to work now:

Code:

SetDlgItemText(hwnd, IDC_MAIN_EDIT, "");

I am calling

Code:

SetDlgItemText(hwnd, IDC_MAIN_EDIT, "");

from a button event in the old WndProc as the button is not subclassed. In other words, how can you send a message from something that isn't subclassed to something that is?
/*Edit:
Also, is WM_SIZE sent to all Window Procedures because the sizing of the edit box is not working correctly?
WM_SIZE is called from the old WndProc before the new WndProc right? */
I tested it and WndProc doesn't call NewWndProc. It still doesn't work - the edit box is rendered useless and the scroll bars are not docked on the side - when I manually call NewWndProc:

Code:

NewWndProc(hwnd, msg, wParam, lParam);

Sorry about the double post, but no matter how many times I go through what code I have I can not find a solution. I have found the answer to the first question - using the GetParent function. Now I am having just as many problems as I was from the last post. I hope that attaching the file will help, as I can't explain the problem very well. It is standalone to make things less confusing.

I have followed your reply but it does not solve any problems. The status bar is only docked to the left of the window (not the other two sides), the edit field is rendered read-only even though the caret appears (it is read-only to the program) and the new, open, save buttons overlap the edit field.
There is also the issue with when the edit field is resized, the window has re-paining problems and merges what used-to take that position on the screen into the edit control (so the edit control could easily contain a picture of a dialog box).
I thought, since all the compilers I have worked with compile the same program differently (and choke more/less on correct code), I have switched from lcc-Win32 to Mingw with Dev-C++ (using the same compiler and OS as Yarin) but after fixing the errors (that lcc didn't have) the program turned out the same with the same problems.
Thanks, Yarin for the suggestion though and this is the best I can describe the problem(s) that have been bugging me for quite a while.

Originally Posted by Yarin

The reason the edit is acting so weird now is because your ONLY calling DefWindowProc from NewWndProc when it gets a WM_CHAR. It needs to be in place of the last return, that way ALL the messages will be processed by DefWindowProc.

I am calling DefWindowProc from NewWndProc when the message isn't WM_CHAR not when it is (note the default case). Also changing the return 0; to:

Code:

return DefWindowProc(hwnd, msg, wParam, lParam);

doesn't fix any of the problems.