{"id":17033,"date":"2009-08-21T10:00:00","date_gmt":"2009-08-21T10:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/08\/21\/restating-the-obvious-about-the-wm_notify-message\/"},"modified":"2009-08-21T10:00:00","modified_gmt":"2009-08-21T10:00:00","slug":"restating-the-obvious-about-the-wm_notify-message","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20090821-00\/?p=17033","title":{"rendered":"Restating the obvious about the WM_NOTIFY message"},"content":{"rendered":"

\nIt appears that people seemed to appreciate\n\nrestating the obvious about the WM_COMMAND<\/code> message<\/a>,\nso I’ll try it again with the WM_NOTIFY<\/code> message.\n<\/p>\n

\nThe WM_NOTIFY<\/code> message is typically used by a control\nto communicate with its parent,\neither to provide information, request it, or both.\nAlthough that is the typical use,\nthere are exceptions.\nFor example, property sheets send the WM_NOTIFY<\/code>\nto their children<\/i>.\nProperty sheets are this sort-of backwards model,\nwhere the common controls provide the parent window (the property sheet)\nand applications provide the child windows (the property sheet pages).\nThe window manager doesn’t care who sends the message to whom,\nas long as the sender and recipient are in the same process.\n<\/p>\n

\nThe message cannot cross a process boundary because WM_NOTIFY<\/code>\nis basically a sender-defined version of WM_USER<\/code>.\nAnybody can define a new notification code and associate it with\nany structure they want (as long as the structure begins with\na NMHDR<\/code>).\nThe window manager can’t marshal the structure between processes\nbecause the structure is defined by the control,\nnot the window manager.\n<\/p>\n

\nA little elaboration of that “sender-defined version of\nWM_USER<\/code>“:\nAs we saw,\n\nthe meaning of WM_USER<\/code> messages is determined by the\nimplementor of the window class<\/a>.\nIn other words, the code receiving<\/i> the message decides what\nWM_USER<\/code> means.\nThat works great if you’re some external code that wants to send a message\nto a known window class.\nBut what if you’re external code that wants to send a message to an\nunknown window class?\nFor example, you’re a list view control and you want to tell your parent\nabout some event.\nYou want to send a message to the parent window,\nbut which message?\nYou can’t send anything in the WM_USER<\/code> range\nbecause each parent window defines independently what those messages mean,\nand it’s highly unlikely that all the parent windows are going to agree\nthat WM_USER+205<\/code> means the same thing.\nFor similar reasons, the WM_APP<\/code> range is no good.\nA registered message would work, but if you have hundreds of potential\nevents, then a hundred registered messages is a bit heavy-handed.\nThe old-school answer to this was the WM_COMMAND<\/code> message,\nwhose notification code is defined by the sending control.\nUnfortunately,\nthe notification code is all you get; the other parameters are busy\ndoing other things.\nEnter WM_NOTIFY<\/code>, which is basically\nWM_COMMAND<\/code> on steroids:\nThe NMHDR<\/code> structure contains everything that was\nin the WM_COMMAND<\/code> message, and since it’s a structure,\nyou can embed the NMHDR<\/code> inside a larger structure\nto provide (and possibly receive) more information.\n<\/p>\n

\nOkay, end of strange digression.\n<\/p>\n

\nThe NMHDR<\/code> structure itself is a convention,\nin the same way that the parameters to WM_COMMAND<\/code>\nare a convention.\nThe hwndFrom<\/code> member is supposed to be the\ncontrol that generated the notification, but there’s\nno enforcement.\n<\/p>\n

\nFirst, there’s no way to enforce it.\nA window doesn’t send a message; code sends a message.\nYou can check the thread that is executing the code that\nis sending a message, but you don’t know which window\nthat code is associated with.\n<\/p>\n

\n“Well, the window that is sending the message is the one\nthat most recently received a message.”\n<\/p>\n

\nThat doesn’t work because you can have code associated\nwith one window call code associated with another window\nwithout actually sending a message.\nIn fact, you probably do this all the time:\n<\/p>\n

\nclass CFrame : public CWindow {\n...\n LRESULT OnCommand(...);\n...\n CGraphWindow *m_pwndGraph;\n};\nLRESULT CFrame::OnCommand(...)\n{\n switch (idFrom) {\n case IDC_CPU: \/\/ user clicked the \"CPU\" button\n  m_pwndGraph->ChangeMode(CPU); \/\/ change to a CPU graph\n  ...\n}\n<\/pre>\n
\nSuppose that CGraphWindow::ChangeMode<\/code> function\ncalls SendMessage<\/code> as part of its processing.\nWhich window “sent” this message?\nSince you have the power to read code, the message was\nconceptually sent by CGraphWindow<\/code>,\nbut the most recently received message is a WM_COMMAND<\/code>\nsent to the frame window.\n<\/p>\n
\nYour method call is just a transfer of control inside your program.\nThe window manager doesn’t know what’s going on.\nAll it knows is that it delivered a WM_COMMAND<\/code> message\nto the frame window, and then some mystery code executed, and\nthe next thing you know, somebody is sending a message.\nIt doesn’t have the source code to your program to know that\n“Oh, that’s coming from CGraphWindow::ChangeMode<\/code>,\nand to get the window handle for CGraphWindow<\/code>,\nI should call CGraphWindow::operator HWND()<\/code>.”\n(And even if it did, imagine your surprise when your breakpoint\non CGraphWindow::operator HWND()<\/code>\ngets hit because SendMessage<\/code> called it!)\n<\/p>\n
\nSecond, even if there were some psychic way for the window\nmanager to figure out which window is sending the message,\nyou still wouldn’t want that.\nIt is common for WM_NOTIFY<\/code> handlers of complex\ncontrols to forward the message to another window.\nFor example, the list view control in report mode\nreceives WM_NOTIFY<\/code>\nmessages from the header control and forwards them\nback out to its own parent,\nso that the list view parent can respond to header notifications.\n(The parent normally should just let the list view handle it,\nbut the operation is performed in case you’re one of those\nspecial cases that needs it.)\n<\/p>\n
\nOkay, back to what the fields of NMHDR<\/code> mean.\nThere are only three fixed fields to NMHDR<\/code> and\nthey pretty much match up with the parameters to\nWM_COMMAND<\/code>:\n<\/p>\n