Date: | October 7, 2004 / year-entry #360 |
Tags: | code |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041007-00/?p=37633 |
Comments: | 6 |
Summary: | Okay, now that we have two context menu handlers we want to compose (namely, the "real" one from the shell namespace and a "fake" one that contains bonus commands we want to add), we can use merge them together by means of a composite context menu handler. The kernel of the composite context menu is... |
Okay, now that we have two context menu handlers we want to compose (namely, the "real" one from the shell namespace and a "fake" one that contains bonus commands we want to add), we can use merge them together by means of a composite context menu handler. The kernel of the composite context menu is to multiplex multiple context menus onto a single context menu handler, using the menu identifer offsets to route the commands. Everything else is just typing. class CCompositeContextMenu : public IContextMenu3 { public: // *** IUnknown *** STDMETHODIMP QueryInterface(REFIID riid, void **ppv); STDMETHODIMP_(ULONG) AddRef(); STDMETHODIMP_(ULONG) Release(); // *** IContextMenu *** STDMETHODIMP QueryContextMenu(HMENU hmenu, UINT indexMenu, UINT idCmdFirst, UINT idCmdLast, UINT uFlags); STDMETHODIMP InvokeCommand( LPCMINVOKECOMMANDINFO lpici); STDMETHODIMP GetCommandString( UINT_PTR idCmd, UINT uType, UINT * pwReserved, LPSTR pszName, UINT cchMax); // *** IContextMenu2 *** STDMETHODIMP HandleMenuMsg( UINT uMsg, WPARAM wParam, LPARAM lParam); // *** IContextMenu3 *** STDMETHODIMP HandleMenuMsg2( UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT* plResult); // Constructor static HRESULT Create(IContextMenu **rgpcm, UINT cpcm, REFIID riid, void **ppv); private: HRESULT Initialize(IContextMenu **rgpcm, UINT cpcm); CCompositeContextMenu() : m_cRef(1), m_rgcmi(NULL), m_ccmi(0) { } ~CCompositeContextMenu(); struct CONTEXTMENUINFO { IContextMenu *pcm; UINT cids; }; HRESULT ReduceOrdinal(UINT_PTR *pidCmd, CONTEXTMENUINFO **ppcmi); private: ULONG m_cRef; CONTEXTMENUINFO *m_rgcmi; UINT m_ccmi; };
The local structure HRESULT CCompositeContextMenu::Initialize( IContextMenu **rgpcm, UINT cpcm) { m_rgcmi = new CONTEXTMENUINFO[cpcm]; if (!m_rgcmi) { return E_OUTOFMEMORY; } m_ccmi = cpcm; for (UINT icmi = 0; icmi < m_ccmi; icmi++) { CONTEXTMENUINFO *pcmi = &m_rgcmi[icmi]; pcmi->pcm = rgpcm[icmi]; pcmi->pcm->AddRef(); pcmi->cids = 0; } return S_OK; }
Since a C++ constructor cannot fail, there are various
conventions for how one handles failure during construction.
One convention, which I use here, is to put the bulk of
the work in an
(Note that here I am assuming a non-throwing
Our initialization function allocates a bunch of
The destructor therefore undoes these operations. CCompositeContextMenu::~CCompositeContextMenu() { for (UINT icmi = 0; icmi < m_ccmi; icmi++) { m_rgcmi[icmi].pcm->Release(); } delete[] m_rgcmi; }
(If you don't understand the significance of the
The HRESULT CCompositeContextMenu::Create(IContextMenu **rgpcm, UINT cpcm, REFIID riid, void **ppv) { *ppv = NULL; HRESULT hr; CCompositeContextMenu *self = new CCompositeContextMenu(); if (self) { if (SUCCEEDED(hr = self->Initialize(rgpcm, cpcm)) && SUCCEEDED(hr = self->QueryInterface(riid, ppv))) { // success } self->Release(); } else { hr = E_OUTOFMEMORY; } return hr; } And then the standard COM bookkeeping. HRESULT CCompositeContextMenu::QueryInterface(REFIID riid, void **ppv) { IUnknown *punk = NULL; if (riid == IID_IUnknown) { punk = static_cast<IUnknown*>(this); } else if (riid == IID_IContextMenu) { punk = static_cast<IContextMenu*>(this); } else if (riid == IID_IContextMenu2) { punk = static_cast<IContextMenu2*>(this); } else if (riid == IID_IContextMenu3) { punk = static_cast<IContextMenu3*>(this); } *ppv = punk; if (punk) { punk->AddRef(); return S_OK; } else { return E_NOINTERFACE; } } ULONG CCompositeContextMenu::AddRef() { return ++m_cRef; } ULONG CCompositeContextMenu::Release() { ULONG cRef = --m_cRef; if (cRef == 0) delete this; return cRef; }
Now we reach our first interesting method:
HRESULT CCompositeContextMenu::QueryContextMenu( HMENU hmenu, UINT indexMenu, UINT idCmdFirst, UINT idCmdLast, UINT uFlags) { UINT idCmdFirstOrig = idCmdFirst; UINT cids = 0; for (UINT icmi = 0; icmi < m_ccmi; icmi++) { CONTEXTMENUINFO *pcmi = &m_rgcmi[icmi]; HRESULT hr = pcmi->pcm->QueryContextMenu(hmenu, indexMenu, idCmdFirst, idCmdLast, uFlags); if (SUCCEEDED(hr)) { pcmi->cids = (USHORT)hr; cids += pcmi->cids; idCmdFirst += pcmi->cids; } } return MAKE_HRESULT(SEVERITY_SUCCESS, 0, cids); }
We ask each contained context menu
in turn to add its commands to the context menu. Here is
where you see one of the reasons for the return value of the
Another reason for the return value of the
HRESULT CCompositeContextMenu::ReduceOrdinal( UINT_PTR *pidCmd, CONTEXTMENUINFO **ppcmi) { for (UINT icmi = 0; icmi < m_ccmi; icmi++) { CONTEXTMENUINFO *pcmi = &m_rgcmi[icmi]; if (*pidCmd < pcmi->cids) { *ppcmi = pcmi; return S_OK; } *pidCmd -= pcmi->cids; } return E_INVALIDARG; }
This method takes a menu offset and figures out which
of the contained context menus it belongs to,
using the return value from
The HRESULT CCompositeContextMenu::InvokeCommand( LPCMINVOKECOMMANDINFO lpici) { CMINVOKECOMMANDINFOEX* lpicix = reinterpret_cast<CMINVOKECOMMANDINFOEX*>(lpici); BOOL fUnicode = lpici->cbSize >= sizeof(CMINVOKECOMMANDINFOEX) && (lpici->fMask & CMIC_MASK_UNICODE); UINT_PTR idCmd = fUnicode ? reinterpret_cast<UINT_PTR>(lpicix->lpVerbW) : reinterpret_cast<UINT_PTR>(lpici->lpVerb); if (!IS_INTRESOURCE(idCmd)) { for (UINT icmi = 0; icmi < m_ccmi; icmi++) { HRESULT hr = m_rgcmi->pcm->InvokeCommand(lpici); if (SUCCEEDED(hr)) { return hr; } } return E_INVALIDARG; } CONTEXTMENUINFO *pcmi; HRESULT hr = ReduceOrdinal(&idCmd, &pcmi); if (FAILED(hr)) { return hr; } LPCWSTR pszVerbWFake; LPCWSTR *ppszVerbW = fUnicode ? &lpicix->lpVerbW : &pszVerbWFake; LPCSTR pszVerbOrig = lpici->lpVerb; LPCWSTR pszVerbWOrig = *ppszVerbW; lpici->lpVerb = reinterpret_cast<LPCSTR>(idCmd); *ppszVerbW = reinterpret_cast<LPCWSTR>(idCmd); hr = pcmi->pcm->InvokeCommand(lpici); lpici->lpVerb = pszVerbOrig; *ppszVerbW = pszVerbWOrig; return hr; } After some preliminary munging to find the command identifier, we dispatch the invocation in three steps. First, if the command is being dispatched as a string, then this is the easiest case. We loop through all the contained context menus asking each one if it recognizes the command. Once one does, we are done. And if nobody does, then we shrug and say we don't know either.
Second, if the command being dispatched is an ordinal,
we ask
Third, we rewrite the Okay, now that you see the basic idea behind distributing the method calls to the appropriate contained context menu, the rest should be comparatively easy. HRESULT CCompositeContextMenu::GetCommandString( UINT_PTR idCmd, UINT uType, UINT * pwReserved, LPSTR pszName, UINT cchMax) { HRESULT hr; if (!IS_INTRESOURCE(idCmd)) { for (UINT icmi = 0; icmi < m_ccmi; icmi++) { hr = m_rgcmi[icmi].pcm->GetCommandString(idCmd, uType, pwReserved, pszName, cchMax); if (hr == S_OK) { return hr; } } if (uType == GCS_VALIDATEA || uType == GCS_VALIDATEW) { return S_FALSE; } return E_INVALIDARG; } CONTEXTMENUINFO *pcmi; if (FAILED(hr = ReduceOrdinal(&idCmd, &pcmi))) { return hr; } return pcmi->pcm->GetCommandString(idCmd, uType, pwReserved, pszName, cchMax); }
The
First, dispatch any string-based commands by calling each
contained context menu handler until somebody accepts it.
If nobody does, then reject the command.
(Note the special handling of
Second, if the command is specified by ordinal, ask
Third, pass the reduced command to the applicable contained context menu handler. The last methods are made easier by a little helper function: HRESULT IContextMenu_HandleMenuMsg2( IContextMenu *pcm, UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT* plResult) { IContextMenu2 *pcm2; IContextMenu3 *pcm3; HRESULT hr; if (SUCCEEDED(hr = pcm->QueryInterface( IID_IContextMenu3, (void**)&pcm3))) { hr = pcm3->HandleMenuMsg2(uMsg, wParam, lParam, plResult); pcm3->Release(); } else if (SUCCEEDED(hr = pcm->QueryInterface( IID_IContextMenu2, (void**)&pcm2))) { if (plResult) *plResult = 0; hr = pcm2->HandleMenuMsg(uMsg, wParam, lParam); pcm2->Release(); } return hr; }
This helper function takes an With this helper function, the last two methods are a piece of cake. HRESULT CCompositeContextMenu::HandleMenuMsg( UINT uMsg, WPARAM wParam, LPARAM lParam) { LRESULT lres; // thrown away return HandleMenuMsg2(uMsg, wParam, lParam, &lres); }
The HRESULT CCompositeContextMenu::HandleMenuMsg2( UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT* plResult) { for (UINT icmi = 0; icmi < m_ccmi; icmi++) { HRESULT hr; if (SUCCEEDED(hr = IContextMenu_HandleMenuMsg2( m_rgcmi[icmi].pcm, uMsg, wParam, lParam, plResult))) { return hr; } } return E_NOTIMPL; }
And the
Armed with this composite menu class, we can show it off
in our sample program by compositing the "real" context menu
with our HRESULT GetCompositeContextMenuForFile(HWND hwnd, LPCWSTR pszPath, REFIID riid, void **ppv) { *ppv = NULL; HRESULT hr; IContextMenu *rgpcm[2] = { 0 }; if (SUCCEEDED(hr = GetUIObjectOfFile(hwnd, pszPath, IID_IContextMenu, (void**)&rgpcm[0])) && SUCCEEDED(hr = CTopContextMenu::Create( IID_IContextMenu, (void**)&rgpcm[1])) && SUCCEEDED(hr = CCompositeContextMenu::Create(rgpcm, 2, riid, ppv))) { // yay } if (rgpcm[0]) rgpcm[0]->Release(); if (rgpcm[1]) rgpcm[1]->Release(); return hr; }
This function builds the composite by creating the two
contained context menu handlers, then creating a composite
context menu that contains both of them. We can use this
function by making the same one-line tweak to the
void OnContextMenu(HWND hwnd, HWND hwndContext, int xPos, int yPos) { POINT pt = { xPos, yPos }; if (pt.x == -1 && pt.y == -1) { pt.x = pt.y = 0; ClientToScreen(hwnd, &pt); } IContextMenu *pcm; if (SUCCEEDED(GetCompositeContextMenuForFile( hwnd, L"C:\\Windows\\clock.avi", IID_IContextMenu, (void**)&pcm))) { ... Notice that with this composite context menu, the menu help text that we update in our window title tracks across both the original file context menu and our "Top" context menu. Commands from either half are also invoked successfully. The value of this approach over the method from part 9 is that you no longer have to coordinate the customization of the context menu between two pieces of code. Under the previous technique, you had to make sure that the code that updated the menu help text was in sync with the code that added the custom commands. Under the new method, all the customizations are kept in one place (in the "Top" context menu which is inside the composite context menu), so that the window procedure doesn't need to know what customizations have taken place. This becomes more valuable if there are multiple points at which context menus are displayed, some uncustomized, others customized in different ways. Centralizing the knowledge of the customizations simplifies the design. Okay, I think that's enough on context menus for now. I hope you've gotten a better understanding of how they work, how you can exploit them, and most importantly, how you can perform meta-operations on them with techniques like composition. There are still some other things you can do with context menus, but I'm going to leave you to experiment with them on your own. For example, you can use the IContextMenu::GetCommandString method to walk the menu and obtain a language-independent command mame for each item. This is handy if you want to, say, remove the "delete" option: You can look for the command whose language-independent name is "delete". This name does not change when the user changes languages; it will always be in English. As we've noticed before, you need to be aware that many context menu handlers don't implement the IContextMenu::GetCommandString method fully, so there will likely be commands that you simply cannot get a name for. Them's the breaks. [Editing errors corrected, 11am.] |
Comments (6)
Comments are closed. |
Since a C++ constructor cannot fail, there are various conventions for how one handles failure during construction. One convention, which I use here, is to put the bulk of the work in an Initialize method, which can return an appropriate error code if the initialization fails.
———
Actually, the way you fail a C++ ctor is to throw an exception. It will unwind the stack properly and will destroy appropriate obects if you throw in the middle of a ctor initialization.
By putting your work in Initialize methods, you run the risk of not having fully formed objects, so that if an exception happens in between your ctor and initialize, your dtor could crash, causing all sorts of badness.
I’ll read the full post during my lunch break, but after a quick skim I’m confused by your CCompositeContextMenu::QueryInterface. If you do these steps:
IUnknown* punk;
punk = static_cast<IContextMenu*>(this);
*ppv = punk;
Won’t the first assignment counteract the cast, since by C++ rules the rvalue gets converted to an IUnknown*? ((IContextMenu*)this) is going to be a different value than ((IUnknown*)this), so wouldn’t *ppv end up pointing at the wrong place in the vtbl?
It’s great to use a throwing model if your entire program follows it, but COM does not allow exceptions to be thrown across the COM boundary.
Mike: I discussed this yesterday in a comment.
http://weblogs.asp.net/oldnewthing/archive/2004/10/06/238630.aspx#239019
The double-cast works due to the rules for COM object layout. COM requires that
(void*)(IBaseInterface*)(IDerivedInterface*)p == (void*)(IDerivedInterface*)p
In other words, the implicit cast to IUnknown is required by COM rules not to change the numeric value of p.
Most C++ compilers for Windows will conform to COM object layout rules if you set the right compiler flags or use the right macros.
http://weblogs.asp.net/oldnewthing/archive/2004/10/05/238050.aspx
Building a new enumerator by combining existing ones.
IContextMenu のホスト方法 – Shell
I’ve been following in awe the series of posts (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) by Raymond Chen about