This is basically used for windows who have its own context menus. The DefWindowProc only works if the window does not display a shortcut menu. In the example I listed in the first submission of the patch, this becomes a problem as the app would need to replace the DefWindowProc with its own version of it via subclassing. By directly sending it to DefWindowProc, windows with its own shortcut menu will not display it correctly.
It is the first sentence in the definition that makes this critical.
Hope you understand.
Mark Lu
On 8/28/06, Huw Davies huw@codeweavers.com wrote:
On Sun, Aug 27, 2006 at 05:35:54PM -0700, Mark Lu wrote:
If the rtf control is a child window AND it doesn't display its own context menu, then the WM_CONTEXTMENU message should be passed to the parent window in the rtf control's DefWindowProc. Here is what MSDN says on the subject:
"If a window does not display a shortcut menu it should pass this message to the DefWindowProc function. If a window is a child window, DefWindowProc sends the message to the parent. Otherwise, DefWindowProc displays a default shortcut menu if the specified position is in the window's caption."
You mention the DefWindowProc behaviour here...
--- a/dlls/riched20/editor.c +++ b/dlls/riched20/editor.c @@ -2318,7 +2319,11 @@ LRESULT WINAPI RichEditANSIWndProc(HWND ME_SelectWord(editor); break; case WM_CONTEXTMENU:
- ME_ShowContextMenu(editor, (short)LOWORD(lParam),
(short)HIWORD(lParam));
- if (!ME_ShowContextMenu(editor, (short)LOWORD(lParam),
(short)HIWORD(lParam)))
- {
if (GetWindowLongW( hWnd, GWL_STYLE ) & WS_CHILD)SendMessageW( GetParent(hWnd), msg, wParam, lParam );- } break; case WM_PAINT: if (editor->bRedraw)
...yet here you send the message to the parent yourself. Why can't you replace this with a 'goto do_default;' and let DefWindowProc do this for you?
Huw.