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?

Are you subclassing the edit box? None of those messages will be sent to your application's window.

When you do subclass, you need to make the subclass proc call the original one BEFORE doing the line check, then return it's value at the end of the line check. Otherwise, your line check will always be one keypress behind realtime.

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.

Yeah, you need to subclass. Look at this.

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, "");

---

1) Yup, everything that the old proc would receive, is received by the new one instead.
2) Where are you calling

Code:

---

SetDlgItemText(hwnd, IDC_MAIN_EDIT, "");

---

from? If it's from the new proc, it should really be

Code:

---

SetWindowText(hwnd, "");

---

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.

Your going about this the wrong way, don't change the edit's size inside it's own proc. Change it inside your main window's proc. Also, when msg is WM_SIZE, lParam contains the new window dimensions (So you don't have to call GetClientRect).

Here, try getting rid of the WM_SIZE handler in your subclass proc, and replace your current main window WM_SIZE handler with this code:

Code:

---

RECT rcTool, rcStatus;
GetWindowRect(GetDlgItem(hwnd, IDC_MAIN_TOOL), &rcTool);
GetWindowRect(GetDlgItem(hwnd, IDC_MAIN_STATUS), &rcStatus);
long iToolHeight = rcStatus.bottom - rcStatus.top;
long iStatusHeight = rcTool.bottom - rcTool.top;
long iEditHeight = HIWORD(lParam) - iToolHeight - iStatusHeight;
SetWindowPos(GetDlgItem(hwnd, IDC_MAIN_EDIT), NULL, 0, iToolHeight, LOWORD(lParam), iEditHeight, SWP_NOZORDER);

---

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.

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.

Quote:

---

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.

Ops, sorry.
You should call the old wnd proc not the def wnd proc.
I noticed your code has a commented out line that saves the old proc, why did you remove it? You need it!

Quote:

---

Originally Posted by Yarin

You should call the old wnd proc not the def wnd proc.

---

I am assuming you mean to use this in the NewWndProc:

Code:

---

default:
    return CallWindowProc(OldWndProc, hwnd, msg, wParam, lParam);

---

Surprisingly, this works (the edit field is type-able and the new/load/save buttons work) in Dev-C++, but not in lccWin32. Thanks Yarin.
The problem I have now is that typing in the edit field does not trigger WM_CHAR messages, which is the reason that I had to subclass the edit field in the first place.

/***FIXED**
Now I just have the strange problem that, when resizing the window, the edit field covers the status bar, along with it not being docked to the top and right hand side of the window. */
This does the trick:

Code:

---

SetWindowPos(GetDlgItem(hwnd, IDC_MAIN_STATUS), NULL, 0, rcClient.bottom - iStatusHeight,
    rcClient.right, iStatusHeight, SWP_NOZORDER);

---

Turns out that it was generating WM_CHAR and WM_KEYDOWN messages, the problem was that I forgot to use:

Code:

---

GetLines(GetParent(hwnd)) //instead of GetLines(hwnd)

---

Thanks for all your help, I never had needed to subclass before so that cleared a few things up. Also, I am going to use Dev-C++ more often and I still think there should be just one compiler that does everything.