Where is the WM_NCHITTEST send? SOLVED

[Vaclav_]

I have a CMDIChildWnd derived frame – a static splitter - and would like to dynamically modify its menu. I used Spy and MFC tracer to find out what messages are send when the mouse hovers over the menu item - WM_NCHITTEST with HTMENU parameter. WindowProc should intercept the message, however the doc is not clear where the message goes, and I cannot see it in the frame. Is there a way to use Spy or MFC trace to find where to process the “nonclient” message? Any help is as always greatly appreciated. Cheers Vaclav Answer To the main frame of the MFC app where OnNcHitTest can process it.

[_Superman_]

The menu belongs to the frame. So you need to create a handler for the WM_NCHITTEST message in the CMDIFrameWnd derived class. The handler would look something like this -

LRESULT CMainFrame::OnNcHitTest(CPoint point)
{
LRESULT result = CMDIFrameWnd::OnNcHitTest(point);

if (HTMENU == result)
{
	AfxMessageBox(L"On the menu");
}

return result;

}

The thing to keep note is that the message box will popup whenever the mouse hovers anywhere on the menu bar and not only on the menu items.

«_Superman_»  _I love work. It gives me something to do between weekends.

_Microsoft MVP (Visual C++) (October 2009 - September 2013)

Polymorphism in C

[Vaclav_]

Thanks for the reply. I can detect the mouse hits, but only on the title bar of the splitter frame. I may have problem with the adittional window whose function is to provide tab access to additional documents. I am still not sure where the message goes from the frame menu. I'll keep working on that, thanks for the suggestion, it really helps. Cheers Vaclav

[Vaclav_]

OK, I am making progress. Using default MDI app I can see the WM_NCHITTEST being processed ( WindowProc) by main frame - the menus hits, and by the doc/view frame - the window title area. I am getting message #867 (?) as hit in my frame menu and WindowsProc in splitter ( my frame) catching it but since it is not near WM_NCHITTEST it is not processed. I need to find out about this rogue 867 message origin.

[_Superman_]

The code that I posted earlier is working code on a default MDI application. Here is some information on command routing in an MDI application - Command Routing Illustration[^] The message #867(0x363) is an internal MFC message defined as - #define WM_IDLEUPDATECMDUI 0x0363 You can find this in the afxpriv.h header file. Here is some information about internal MFC messages - MFC Defined Messages[^] Here is an excerpt from the above link - WM_IDLEUPDATECMDUI This message is sent in idle time to implement the idle-time update of update-command UI handlers.

«_Superman_»  _I love work. It gives me something to do between weekends.

_Microsoft MVP (Visual C++) (October 2009 - September 2013)

Polymorphism in C

[Vaclav_]

Thanks for the update. In retrospect - my "mistake" was not understanding how main frame non-client message gets back to windows message processing. After accessing the current active MDI frame I have a better understanding of things. Of couse few "new" documents ( DirectShow graph) insterted during test and left in did not help. Many thanks for your assistance, appreciate it. Vaclav