How to know if someone else handled OnContextMenu - mfc

I have a CWnd derived class that has a WM_CONTEXTMENU handler (OnContextMenu), which has my default context menu. This class is being used at several places in my application.
Some of the places where it's being used also handle the WM_CONTEXTMENU at the parent level (the window parent). They basically override the default context menu.
When I am inside the CWnd derived class, I basically want to know if someone else (a window parent) handled the context menu.
for example:
void MyDerivedWnd::OnContextMenu( CWnd* in_pWnd, CPoint in_point )
{
LRESULT res = __super::Default();
// Now, how to I know of something happened inside __super::Default();??
// Show my default menu
// ...
}
It is possible via the Win32/MFC framework?

I found a way to discover if something happened during the default handler implementation. It may not be the most elegant solution, but here it is:
bool g_bWindowCreated = false;
HHOOK g_hHook = NULL;
LRESULT CALLBACK HookProc(int code, WPARAM wParam, LPARAM lParam)
{
if( code == HCBT_CREATEWND )
g_bWindowCreated = true;
return CallNextHookEx( g_hHook, code, wParam, lParam );
}
void MyDerivedWnd::OnContextMenu( CWnd* in_pWnd, CPoint in_point )
{
// Setup a hook to know if a window was created during the
// Default WM_CONTEXT_MENU handler
g_bWindowCreated = false;
g_hHook = SetWindowsHookEx( WH_CBT, HookProc, NULL, GetCurrentThreadId() );
// Call the default handler
LRESULT res = __super::Default();
UnhookWindowsHookEx( g_hHook );
if( !g_bWindowCreated )
{
// Show my default menu
// ...
}
}

Related

How to change default position of pop-up window in MFC

I have an MFC application and I want all pop-up generated by this application as dialog box or using AfxMessageBox should be positioned to some location given in config file.
Is there a way in MFC to set the default position for any pop-up window ?
Thanks in advance
Easily done with a window hook procedure.
Consult this SO post: Hooking window creation in an MFC program
Sample code:
static HHOOK g_myHook = NULL;
LRESULT CALLBACK MyCbtHook(int nCode, WPARAM wParam, LPARAM lParam)
{
switch (nCode)
{
case HCBT_ACTIVATE:
{
CWnd* wnd = CWnd::FromHandle((HWND)wParam);
WINDOWINFO wi;
wi.cbSize = sizeof(wi);
wnd->GetWindowInfo(&wi);
if ((wi.dwStyle & WS_POPUPWINDOW) == WS_POPUPWINDOW)
{
wnd->SetWindowPos(NULL, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOZORDER);
}
break;
}
}
return CallNextHookEx(0, nCode, wParam, lParam);
}
static void InstallHook()
{
g_myHook = SetWindowsHookEx(WH_CBT, MyCbtHook, 0, GetCurrentThreadId());
}
static void UninstallHook()
{
if (g_myHook)
{
UnhookWindowsHookEx(g_myHook);
g_myHook = NULL;
}
}
Call InstallHook in the InitInstance, then UninstallHook in the ExitInstance (not required really).
This sample hook procedure moves all popup window to the top left corner.

Use class member as WNDPROC/DLGPROC with or without global

I'll go ahead and give a summary to this, how can I use a dialog procedure that is a member of a class? I am creating a window wrapper class, but CreateDialogParam needs a global dialog procedure, so I tried this workaround:
I have done a bit of searching on this topic. I am making a Dialog class which I am subclassing to make a CMainWnd and then instantiating that. In the Dialog class I have a member function defined as INT_PTR CALLBACK Dialog::cb_proc(HWND,UINT,WPARAM,LPARAM). Now, I know that windows must have a global function as a callback procedure.
So I made a std::map<HWND,Dialog*> DlgProcs map to associate the dialogs window handle with its Dialog class pointer.
And a INT_PTR CALLBACK DlgMainProc(HWND,UINT,WPARAM,LPARAM) so I could pass that to CreateDialogParam(). In the body of DlgMainProc(...) I search the map for using the hWnd parameter to find the Dialog* and return its cb_proc(..) member.
My problem is that none of the messages get processed, this is because the member procedure in my Dialog class never gets called. Even though when I put a MessageBox() in DlgMainProc inside a if (DlgProcs.find(hWnd) != DlgProcs.end()) { statement, the messagebox is displayed, over and over again until I have to abort the program from Visual Studio 2008. Which tells me that it is finding the hWnd in my map. The weird thing is it also does this if I put it in the else statement after that, which contradictingly tells me it is NOT finding the hWnd in the map.
If I put a messagebox in the cb_proc member function it does not get displayed at all. But during this I never get any compiler, linker, or runtime errors. When I remove the messagebox from it (as to not have to abort the program, it was just for debugging purposes) the program runs but no messages get processed, the X button does not close the program, button clicks do nothing.
Here is the PasteBin code: http://pastebin.com/GsGUBpZU
Btw, I have no problem subclassing this, my window is created fine, just no messages are processed, cb_proc just never gets called.
EDIT: Here is the relevant parts of the code
map<HWND,Dialog*> g_DlgProcs;
INT_PTR CALLBACK g_MainDlgProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {
if (g_DlgProcs.find(hWnd) != g_DlgProcs.end()) {
Alert("blah"); // Gets executed repeatedly
return g_DlgProcs[hWnd]->cb_proc(hWnd, msg, wParam, lParam);
} else {
Alert("blah"); // Removing the above alert, this gets
// executed repeatedly, erm, as well.. O.o strange
return FALSE;
}
}
Dialog::Dialog(int id, HWND parent /* = HWND_DESKTOP */) {
_id = id;
_parent = parent;
// Tried this before CreateDialogParam
g_DlgProcs.insert(make_pair(_handle, this));
_handle = CreateDialogParam(
(HINSTANCE)GetModuleHandle(NULL),
MAKEINTRESOURCE(id), _parent,
(DLGPROC)g_MainDlgProc, NULL
);
// Then tried it after CreateDialogParam
g_DlgProcs.insert(make_pair(_handle, this));
}
INT_PTR CALLBACK Dialog::cb_proc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {
Alert("blah"); // Never gets executed
bool handled = true;
switch (msg)
{
case WM_INITDIALOG:
OnInitialize();
break;
case WM_COMMAND:
if (HIWORD(wParam) == 0 || HIWORD(wParam) == 1) {
OnMenuCommand((HIWORD(wParam) == 1), (int)LOWORD(wParam));
} else {
OnCtrlCommand((int)HIWORD(wParam), (int)LOWORD(wParam), (HWND)lParam);
}
break;
case WM_NOTIFY:
{
LPNMHDR head = (LPNMHDR)lParam;
OnNotification(head->code, head->idFrom, head->hwndFrom);
}
break;
case WM_CLOSE:
OnClose(); // DestroyWindow(_handle)
break;
case WM_DESTROY:
OnDestroy(); // PostQuitMessage(0)
default:
handled = ProcessMsg(msg, wParam, lParam);
}
// Convert bool to Windows BOOL enum
return ((handled == true) ? TRUE : FALSE);
}
Does anybody know why it never gets called? Or maybe just guide me to another way to use a member function as a DLGPROC?
The standard solution is to pass your this pointer as the last parameter to Create,DialogParam, stash it in DWLP_USER in your WM_INITDIALOG handler, and retrieve it from DWLP_USER thereafter. Basically you use DWLP_USER as your map.
I tried your code and it worked: cb_proc gets called. You will miss any messages (e.g. WM_INITDIALOG) that get sent before CreateDialogParam returns.
You can fix the latter problem by adding the window handle and the object to the map in g_MainDlgProc. If you get a message for an unknown window, you know it belongs to the window you're creating; put the object in a global and you can add the handle/object to the map.
I'm just adding this here in case someone finds it useful; using the magic of C++11 lambdas and templates you can have a simple wrapper template that means you don't have to continually rewrite the boiler-plate code for saving and loading userdata in window and dialog box procedures.
Here's an example for the DialogBoxParam function, but the same technique can be applied to CreateDialogParam and CreateWindowEx as well.
template <typename T, INT_PTR (T::*P)(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)>
INT_PTR DialogBoxThis(T* pThis, HINSTANCE hInstance, LPCWSTR lpTemplateName, HWND hWndParent)
{
return ::DialogBoxParam(hInstance, lpTemplateName, hWndParent, [](HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) -> INT_PTR {
if (uMsg == WM_INITDIALOG) SetWindowLongPtr(hWnd, DWLP_USER, lParam);
T* pThis = reinterpret_cast<T*>(GetWindowLongPtr(hWnd, DWLP_USER));
return pThis ? (pThis->*P)(hWnd, uMsg, wParam, lParam) : FALSE;
}, reinterpret_cast<LPARAM>(pThis));
}
You would use it like this:
class MyClass
{
INT_PTR MyDlgProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
};
// from inside MyClass, we can show a dialog that uses member function MyDlgProc as the dialog procedure
// note it is NOT a static function
DialogBoxThis<MyClass, &MyClass::MyDlgProc>(this, hInstance,
MAKEINTRESOURCE(IDD_MYDIALOG), hWndParent);

Why does there OnFinalMessage never be called in ATL?

I am using ATL do build my software. I create a main frame window which contain serviral childen windows. the one of the childen windows contain some chinden windows also.
Now, my app will alway get the failed of assert:
virtual ~CWindowImplRoot()
{
#ifdef _DEBUG
if(m_hWnd != NULL) // should be cleared in WindowProc
{
ATLTRACE(atlTraceWindowing, 0, _T("ERROR - Object deleted before window was destroyed\n"));
ATLASSERT(FALSE);
}
#endif //_DEBUG
}
I defined WM_NCDESTROY handler for any window and set bHanded=FALSE, the code can arrived there.
Anymore, I add OnFinalMessage override function. unfortunatelly, no all of the functions can be called. Actually, the top-level window's OnFinalMessage will be called, the middle-level windows' OnFinalMessage may not be called, the bottom-level windows' OnFinalMessage will never be called.
I oberve the source code of ATL:
template <class TBase, class TWinTraits>
LRESULT CALLBACK CWindowImplBaseT< TBase, TWinTraits >::WindowProc(
_In_ HWND hWnd,
_In_ UINT uMsg,
_In_ WPARAM wParam,
_In_ LPARAM lParam)
{
CWindowImplBaseT< TBase, TWinTraits >* pThis = (CWindowImplBaseT< TBase, TWinTraits >*)hWnd;
// set a ptr to this message and save the old value
_ATL_MSG msg(pThis->m_hWnd, uMsg, wParam, lParam);
const _ATL_MSG* pOldMsg = pThis->m_pCurrentMsg;
pThis->m_pCurrentMsg = &msg;
// pass to the message map to process
LRESULT lRes = 0;
BOOL bRet = pThis->ProcessWindowMessage(pThis->m_hWnd, uMsg, wParam, lParam, lRes, 0);
// restore saved value for the current message
ATLASSERT(pThis->m_pCurrentMsg == &msg);
// do the default processing if message was not handled
if(!bRet)
{
if(uMsg != WM_NCDESTROY)
lRes = pThis->DefWindowProc(uMsg, wParam, lParam);
else
{
// unsubclass, if needed
LONG_PTR pfnWndProc = ::GetWindowLongPtr(pThis->m_hWnd, GWLP_WNDPROC);
lRes = pThis->DefWindowProc(uMsg, wParam, lParam);
if(pThis->m_pfnSuperWindowProc != ::DefWindowProc && ::GetWindowLongPtr(pThis->m_hWnd, GWLP_WNDPROC) == pfnWndProc)
::SetWindowLongPtr(pThis->m_hWnd, GWLP_WNDPROC, (LONG_PTR)pThis->m_pfnSuperWindowProc);
// mark window as destryed
pThis->m_dwState |= WINSTATE_DESTROYED;
}
}
if((pThis->m_dwState & WINSTATE_DESTROYED) && pOldMsg== NULL)
{
// clear out window handle
HWND hWndThis = pThis->m_hWnd;
pThis->m_hWnd = NULL;
pThis->m_dwState &= ~WINSTATE_DESTROYED;
// clean up after window is destroyed
pThis->m_pCurrentMsg = pOldMsg;
pThis->OnFinalMessage(hWndThis);
}else {
pThis->m_pCurrentMsg = pOldMsg;
}
return lRes;
}
In above code, the purpose of the variable "pOldMsg" is to indicate the call stack level. if "pOldMsg" not equal to NULL, it's means that the call stack is not returned. when it's NULL, means the the call stack is outermost level, this moment we can call OnFinalMessage function now.
In my case, it's seems that sometimes "pOldMsg" will never equal to NULL.
chat:
MainFrame V
|----- ViewDevices V
|----- ViewContainer X
|----- ViewBooks X
|----- ViewFiles V
After testing it for many times, I find that, if I didn't add any content to the ViewBooks(ListView) window, every things is OK. Once I add just a line, this issue will repro. I don't know whether the sending message by crossing thread cause the issue.
Can anybody give me some suggestions?

Window Procedure Not Being Called By Message Handler

I am writing a Windows Api wrapper and I have run into a problem. I am abstracting the Window Procedure (WndProc) and wrote a static MsgHandler which would call the WndProc of my WinHandler class. Here is the code:
LRESULT CALLBACK WinHandle::MsgHandler(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam)
{
WinHandle* wnd = 0;
if (msg == WM_NCCREATE)
{
::SetWindowLong(hwnd,GWL_USERDATA,
long((LPCREATESTRUCT(lParam))->lpCreateParams));
}
wnd = (WinHandle*) (::GetWindowLong(hwnd,GWL_USERDATA));
if (wnd)
return wnd->WndProc(msg,wParam,lParam);
else
return ::DefWindowProc(hwnd,msg,wParam,lParam);
}
Since this functions is static , there is no this pointer and it works perfectly with WNDCLASSEX, but for some reason it never calls wnd->WndProc() and always returns the default window procedure. Need Help. What is wrong? Does anyone know a better approach?
Call SetWindowLong when you receive WM_CREATE, not WM_NCCREATE. I don't think lpCreateParams is valid in WM_NCCREATE. That is:
if (msg == WM_CREATE)
{
::SetWindowLong(hwnd,GWL_USERDATA,
long((LPCREATESTRUCT(lParam))->lpCreateParams));
}

Safely remove window subclassing?

I am trying to subclass the currently focused window on a Windows system using a global CBT hook. This is related to what happens in this question, but the bug is different.
What happens when this subclassing is in effect, is that Opera's (version 10.50) main window is prevented from displaying. Opera has a "splash screen" where you are required to click "Start" for the main window to show that appears after Opera has not shut down properly. Whenever this window pops up, Opera's main window won't show. If Opera was shut down properly, and this splash screen does not show, the main window displays as it should.
HHOOK hHook;
HWND hWndSubclass = 0;
void SubclassWindow(HWND hWnd)
{
Unsubclass();
FARPROC lpfnOldWndProc = (FARPROC)SetWindowLongPtr(hWnd, GWLP_WNDPROC, (LPARAM)SubClassFunc);
SetProp(hWnd, L"PROP_OLDWNDPROC", lpfnOldWndProc);
hWndSubclass = hWnd;
}
void Unsubclass()
{
if (hWndSubclass != 0 && IsWindow(hWndSubclass))
{
FARPROC lpfnOldWndProc = (FARPROC)GetProp(hWndSubclass, L"PROP_OLDWNDPROC");
RemoveProp(hWndSubclass, L"PROP_OLDWNDPROC");
SetWindowLongPtr(hWndSubclass, GWLP_WNDPROC, (LPARAM)lpfnOldWndProc);
hWndSubclass = 0;
}
}
static LRESULT CALLBACK SubClassFunc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
if (message == WM_MOVING)
{
// do something irrelevant
}
else if (message == WM_DESTROY)
{
Unsubclass();
}
FARPROC lpfnOldWndProc = (FARPROC)GetProp(hWndSubclass, L"PROP_OLDWNDPROC");
return CallWindowProc((WNDPROC)lpfnOldWndProc, hWndSubclass, message, wParam, lParam);
}
static LRESULT CALLBACK CBTProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if (nCode == HCBT_SETFOCUS && hWndServer != NULL)
{
SubclassWindow((HWND)wParam);
}
if (nCode < 0)
{
return CallNextHookEx(hHook, nCode, wParam, lParam);
}
return 0;
}
BOOL APIENTRY DllMain( HINSTANCE hInstance,
DWORD Reason,
LPVOID Reserved
)
{
switch(Reason)
{
case DLL_PROCESS_ATTACH:
hInst = hInstance;
return TRUE;
case DLL_PROCESS_DETACH:
Unsubclass();
return TRUE;
}
return TRUE;
}
My suspicion is that Opera's main window is somehow already subclassed. I imagine the following is happening:
The window is created with it's own basic WndProc, and is given focus
My application subclasses the window, storing the original WndProc
Opera subclasses its own window
When the window loses focus, I restore the original WndProc, thus ignoring the second WndProc
Can this really be the case? Are there any other explanations?
This can happen, as Raymond Chen writes:
Consider what would happen if somebody else had subclassed the window during the "... do stuff ..." section. When we unsubclassed the window, we would have removed two subclasses, the one we installed, and the one that was installed after us. If the other subclass allocated memory (which is very common), then that memory got leaked, in addition to the subclass failing to do whatever it was trying to do.
He continues with a solution:
This is quite a cumbersome process, so the shell team wrote some helper functions to do all this for you. The SetWindowSubclass function does all the grunt work of installing a subclass procedure, remembering the previous one, and passing reference data to the subclass procedure you provide. You use the DefSubclassProc function to forward the message to the previous subclass procedure, and when you're done, you use the RemoveWindowSubclass function to remove yourself from the chain. RemoveWindowSubclass does all the work to do the right thing if you are not the window procerure at the top of the chain.