Ribbon Repurposing with a Native C++ Addin

[Mark Wilson]

I have a C++ native COM addin (not ATL) and one of the things
it needs to do is repurpose one of the Outlook buttons on the Ribbon.

There are a couple of questions that I need some answers on.

1) With an ECE, when a command is intercepted with IExchExtCommands:oCommand
returning S_OK means that the ECE processed the command and
returning S_FALSE means that the ECE did not process the
command and Outlook should do it. Is this possible to do this
type of operation with an Outlook COM addin?


2) If it is possible, then when the Invoke method is called to process
a repurposed button's click event, how does the Invoke method pass
information back to Outlook to signify that the Outlook command
has been processed by MyButtonClick or ignored (allowing Outlook
to do normal processing on the click event)?

STDMETHODIMP CMyAddin::Invoke(DISPID dispIdMember,
REFIID riid,
LCID lcid,
WORD wFlags,
DISPPARAMS FAR* pDispParams,
VARIANT FAR* pVarResult,
EXCEPINFO FAR* pExcepInfo,
unsigned int FAR* puArgErr)
{
IDispatch * pIDisp = pDispParams->rgvarg[0].pdispVal;
BOOL bCancelDefault;

if (dispIdMember == 0x000A)
MyButtonClick(pIDisp, &bCancelDefault);

return S_OK;
}

 

[Colbert Zhou [MSFT]]

Hello Max,

1).Yes. In C++ native COM AddIn, Outlook object model also supports the
button click event. The bCancel parameter is passed via DISPPARAMS*
pDispParams.

2). Typically, we should have the following codes,

/******************************************************************
* CButtonHandler::Invoke()
*
* The click event is fired by this Invoke call. There is only
* one event for this interface (0x00000001) and it takes two
* parameters:
*
* LPDISPATCH pCtrl -- The primary interface of the button
* being pressed.
*
* VARIANT_BOOL bCancel -- Determines whether the default action
* should be cancled.
*
******************************************************************/
STDMETHODIMP CButtonHandler::Invoke(DISPID dispIdMember, REFIID riid, LCID
lcid, WORD wFlags, DISPPARAMS* pDispParams, VARIANT* pVarResult, EXCEPINFO*
pExcepInfo, UINT* puArgErr)
{
*V_BOOLREF(&pDispParams->rgvarg[1]) = VARIANT_TRUE;
return S_OK;
}

You can refer to the KB article to get a sample on a native Outlook COM
Addin,
http://support.microsoft.com/kb/230689


Best regards,
Ji Zhou
Microsoft Online Community Support

 

[Mark Wilson]

Ji, maybe I'm missing something.

In this test I'm trying to repurpose the Print button. The DISPID I have
assigned to the event is 0x0000000A so my code looks like this.

STDMETHODIMP CMyAddin::Invoke(DISPID dispIdMember,
REFIID riid, LCID lcid, WORD wFlags,
DISPPARAMS* pDispParams, VARIANT* pVarResult,
EXCEPINFO* pExcepInfo, UINT* puArgErr)
{
if (dispIdMember == 0X0000000A)
{
*V_BOOLREF(&pDispParams->rgvarg[1]) = VARIANT_TRUE;
}

return S_OK;
}

If I set rgvarg[1] then Outlook crashes some time after the Invoke call
completes. If I comment that line out then Outlook does not crash. There is
no crash address. The Inspectors and Explorer just disappear.

I'll try simplifying my code and see if I can narrow this down.
CMyAddin::Invoke also processes other RibbonX events like getLabel and
getImmage for other custom Ribbon buttons. (I don't think that would cause
any issues.)

 

[Mark Wilson]

Hi Ji.

I've used your reference KB article as a base for my test and added RibbonX
support for a couple of custom buttons and the FilePrint button. All works
fine until I add the line of code you suggested. After exiting the Invoke
method there is a long delay and the Outlook process disappears with no
error/warning messages displayed.

 

[Colbert Zhou [MSFT]]

Hello Mark,

I replied you an email. We will follow up on this issue via email. Have
a nice weekend, sir!


Best regards,
Ji Zhou
Microsoft Online Community Support