MDPE
March 1st, 2006, 04:12 PM
I sub-classed a rich edit control and I’ve found it has caused the border of the control to stop being repainted, though the client area still repaints normally. It therefore comes out looking like this, where the green area is the client area and the mess is the border after dragging a window over it:
http://img2.uploadimages.net/360421border.jpg
The subclassed window procedure processes a few message (WM_GETDLGCODE , WM_CHAR and WM_KEYDOWN) in the switch case and has a default case of:
return CallWindowProc(g_pOldCommandEditProc, hEditWnd, mMsg, wParam, lParam);
I thought the default rich edit control window procedure would handle the redrawing of the border but that isn’t happening.
I’m new to windows programming and really don’t know what to do. I’ve tried a variety of things like calling ReddrawWindow() with RDW_FRAME from WM_PAINT but nothing worked.
Can anyone possibly direct me to where the problem might be?
Thanks for any help you can offer.
Some12k
March 2nd, 2006, 01:47 PM
Add WS_EX_CLIENTEDGE textbox' extended style.
MDPE
March 2nd, 2006, 09:23 PM
Thanks for the reply. I already have that as the extended style:
HWND hEdit = CreateWindowEx(WS_EX_CLIENTEDGE,
RICHEDIT_CLASS,
"",
WS_CHILD | WS_VISIBLE,
0, 0, 0, 0,
hWnd,
HMENU(IDC_COMMAND_EDIT_CTRL),
GetModuleHandle(NULL),
NULL);
From everything I've read it seems that it's not the programmer's responsibility to redraw the border so i think I must have broken something in subclassing the edit control. Here's where that's done:
g_pOldCommandEditProc = WNDPROC(SetWindowLong(hEdit, GWL_WNDPROC, LONG(commandBoxSubClassProc)));
Here's the edit control window procedure, which is just there to capture the enter key being pressed:
LRESULT CALLBACK commandBoxSubClassProc(HWND hEditWnd, WORD mMsg, WORD wParam, LONG lParam)
{
switch (mMsg)
{
case WM_GETDLGCODE : return long((DLGC_WANTALLKEYS | CallWindowProc(g_pOldCommandEditProc, hEditWnd, mMsg, wParam, lParam)));
break;
case WM_CHAR : if (wParam == VK_RETURN)
return 0;
return long(CallWindowProc(g_pOldCommandEditProc, hEditWnd, mMsg, wParam, lParam));
break;
case WM_KEYDOWN : return g_cwChildWindows.getCommandBoxPt()->processCommandKeys(hEditWnd, mMsg, wParam, lParam);
break;
default : return CallWindowProc(g_pOldCommandEditProc, hEditWnd, mMsg, wParam, lParam);
break;
}
}
I'm the first to admit I don't know what I'm doing but that all seems fine to me.
The other thing it might be is the message loop for the main window:
while (GetMessage(&mMsg, NULL, 0, 0))
I'm using NULL for the handle of the window, which gets the messages for all windows so I think the messages for the subclassed edit control might be going to the main window and that's why the border isn't redrawing. However, other messages for the edit control seem to work okay.
Changing the NULL to the main window handle stops the program exiting properly (the main window disappears but the program is still running and using 99% of the processor time) and changing it doesn't fix the border redraw problem anyway.
I can't find what the problem is.
MDPE
March 6th, 2006, 09:37 PM
Still can't work out what's wrong. If I remove the line to subclass the edit control the border redraws fine, so I know where things are going wrong but not what I have to do to fix it.
kkez
March 7th, 2006, 05:32 AM
LRESULT CALLBACK commandBoxSubClassProc(HWND hEditWnd, WORD mMsg, WORD wParam, LONG lParam)
{
switch (mMsg)
{
case WM_GETDLGCODE:
return DLGC_WANTALLKEYS;
case WM_CHAR:
if (wParam == VK_RETURN) return 0;
break;
case WM_KEYDOWN:
return g_cwChildWindows.getCommandBoxPt()->processCommandKeys(hEditWnd, mMsg, wParam, lParam);
}
return CallWindowProc(g_pOldCommandEditProc, hEditWnd, mMsg, wParam, lParam);
}
(You can get rid of all those break/return/badly formatted code)
The problem may be in the WM_GETDLGCODE handler.