command bars in new explorer

If Outlook doesn't close down completely (in my case, another add-in is
running that apparently doesn't release all of its resources properly) and I
"start" Outlook again, I get a NewExplorer event when the main window pops
up again. When I call Explorer::get_CommandBars so I can add my command
bar, it fails, with an HRESULT that appears to be garbage, since it is
different every time.

I haven't tested this behavior with a NewExplorer event under normal
circumstances, because I don't know how to make one happen under normal
circumstances.

The odd thing is that the add-in that is causing this problem doesn't have
any problem creating its own toolbar in this case.

Can anybody help with this?

Mark

What is the exact failing code? Do you check that the toolbar already
exists?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Mark Smith" <its@online.nospam> wrote in message
news:%235NtOfDIFHA.560@TK2MSFTNGP12.phx.gbl...
> If Outlook doesn't close down completely (in my case, another add-in is
> running that apparently doesn't release all of its resources properly) and
> I "start" Outlook again, I get a NewExplorer event when the main window
> pops up again. When I call Explorer::get_CommandBars so I can add my
> command bar, it fails, with an HRESULT that appears to be garbage, since
> it is different every time.
>
> I haven't tested this behavior with a NewExplorer event under normal
> circumstances, because I don't know how to make one happen under normal
> circumstances.
>
> The odd thing is that the add-in that is causing this problem doesn't have
> any problem creating its own toolbar in this case.
>
> Can anybody help with this?
>
> Mark
>

Well, here are a few of the HRESULTs that I have
gotten: -1733279739, -1594867707, -1456455675, -1318043643.

I'm not sure what you mean by checking if the toolbar already exists.
get_CommandBars is failing, so I can't check anything about the command
bars. The original toolbar was removed when the Explorer OnClose event was
received as Outlook was "closing".

Mark

"Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
news:OQg99yEIFHA.1172@TK2MSFTNGP12.phx.gbl...
> What is the exact failing code? Do you check that the toolbar already
> exists?
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool
>
> "Mark Smith" <its@online.nospam> wrote in message
> news:%235NtOfDIFHA.560@TK2MSFTNGP12.phx.gbl...
>> If Outlook doesn't close down completely (in my case, another add-in is
>> running that apparently doesn't release all of its resources properly)
>> and I "start" Outlook again, I get a NewExplorer event when the main
>> window pops up again. When I call Explorer::get_CommandBars so I can add
>> my command bar, it fails, with an HRESULT that appears to be garbage,
>> since it is different every time.
>>
>> I haven't tested this behavior with a NewExplorer event under normal
>> circumstances, because I don't know how to make one happen under normal
>> circumstances.
>>
>> The odd thing is that the add-in that is causing this problem doesn't
>> have any problem creating its own toolbar in this case.
>>
>> Can anybody help with this?
>>
>> Mark
>>
>
>

So what is your code?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Mark Smith" <its@online.nospam> wrote in message
news:%234KT8tMIFHA.2700@TK2MSFTNGP09.phx.gbl...
> Well, here are a few of the HRESULTs that I have
> gotten: -1733279739, -1594867707, -1456455675, -1318043643.
>
> I'm not sure what you mean by checking if the toolbar already exists.
> get_CommandBars is failing, so I can't check anything about the command
> bars. The original toolbar was removed when the Explorer OnClose event
> was received as Outlook was "closing".
>
> Mark
>
> "Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
> news:OQg99yEIFHA.1172@TK2MSFTNGP12.phx.gbl...
>> What is the exact failing code? Do you check that the toolbar already
>> exists?
>>
>> Dmitry Streblechenko (MVP)
>> http://www.dimastr.com/
>> OutlookSpy - Outlook, CDO
>> and MAPI Developer Tool
>>
>> "Mark Smith" <its@online.nospam> wrote in message
>> news:%235NtOfDIFHA.560@TK2MSFTNGP12.phx.gbl...
>>> If Outlook doesn't close down completely (in my case, another add-in is
>>> running that apparently doesn't release all of its resources properly)
>>> and I "start" Outlook again, I get a NewExplorer event when the main
>>> window pops up again. When I call Explorer::get_CommandBars so I can
>>> add my command bar, it fails, with an HRESULT that appears to be
>>> garbage, since it is different every time.
>>>
>>> I haven't tested this behavior with a NewExplorer event under normal
>>> circumstances, because I don't know how to make one happen under normal
>>> circumstances.
>>>
>>> The odd thing is that the add-in that is causing this problem doesn't
>>> have any problem creating its own toolbar in this case.
>>>
>>> Can anybody help with this?
>>>
>>> Mark
>>>
>>
>>
>
>

Well, in OnStartupComplete I set up the NewExplorer event:

STDMETHODIMP CAddin::OnStartupComplete(LPSAFEARRAY* custom)
{
// Check internal state
if (m_pApplication == NULL)
return E_FAIL;

. . .

hr = m_pApplication->get_Explorers(&m_pExplorers);
if (FAILED(hr) || m_pExplorers == NULL) {
char pBuf[256];
sprintf(pBuf, "Unable to add tool bar to window\n HRESULT %d\n
Location: 4", hr);
errorBox(pBuf);
}
else {
hr = IDispEventSimpleImpl<4, CAddin,
&__uuidof(Outlook::ExplorersEvents)>:ispEventAdvise(static_cast<IDispatch*>(m_pExplorers),
&DIID_ExplorersEvents);
if (FAILED(hr)) {
char pBuf[256];
sprintf(pBuf, "Unable to add tool bar to window\n HRESULT %d\n
Location: 5", hr);
errorBox(pBuf);
}
else {
m_bReleaseExplorersEvents = true;
}
}

return S_OK;
}

The NewExplorer event creates a newToolBar, which wraps up the command bar
and event handling code:

void __stdcall CAddin::NewExplorer(IDispatch* _pdispExplorer)
{
// Add tool bar
addToolBar(new ToolBar(CComQIPtr<Outlook::_Explorer>(_pdispExplorer),
this));
}

The addToolBar function adds to thw list of toolbars:

HRESULT CAddin::addToolBar(ToolBar* _pToolBar)
{
// Check input
if (_pToolBar == NULL) {
errorBox("Unable to add tool bar to window\n Cause: Out of memory\n
Location: 1");
return E_FAIL;
}
const HRESULT hr = _pToolBar->getResult();
if (FAILED(hr)) {
delete _pToolBar;
return hr;
}

// Allocate list memory
void* const pBuffer = realloc(m_ppToolBars, (m_NumToolBars + 1) *
sizeof(ToolBar*));
if (pBuffer == NULL) {
delete _pToolBar;
errorBox("Unable to add tool bar to window\n Cause: Out of memory\n
Location: 2");
return E_FAIL;
}

// Add tool bar
m_ppToolBars = static_cast<ToolBar**>(pBuffer);
m_ppToolBars[m_NumToolBars++] = _pToolBar;
return S_OK;
}

Then the ToolBar constructor calls addToolBar to actually create the new
toolbar and button:

ToolBar::ToolBar(Outlook::_Explorer* _pExplorer, CAddin* _pParent)
{
if (_pExplorer == NULL) {
ATLASSERT(_pExplorer);
return;
}

m_Result = _pExplorer->get_CommandBars(&m_pCommandBars);
if (FAILED(m_Result) || m_pCommandBars == NULL) {
char pBuf[256];
sprintf(pBuf, "Unable to add tool bar to window\n HRESULT: %d\n
Location: 1", m_Result);
errorBox(pBuf);
return;
}

m_Result = addToolBar();
if (FAILED(m_Result) || m_pCommandBar == NULL) {
char pBuf[256];
sprintf(pBuf, "Unable to add tool bar to window\n HRESULT: %d\n
Location: 2", m_Result);
errorBox(pBuf);
return;
}
}

addToolBar is not important for this case, since it is failing at
get_CommandBars, before addToolBar even gets called.

Mark

"Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
news:uOZrX4NIFHA.2784@TK2MSFTNGP09.phx.gbl...
> So what is your code?
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool
>
> "Mark Smith" <its@online.nospam> wrote in message
> news:%234KT8tMIFHA.2700@TK2MSFTNGP09.phx.gbl...
>> Well, here are a few of the HRESULTs that I have
>> gotten: -1733279739, -1594867707, -1456455675, -1318043643.
>>
>> I'm not sure what you mean by checking if the toolbar already exists.
>> get_CommandBars is failing, so I can't check anything about the command
>> bars. The original toolbar was removed when the Explorer OnClose event
>> was received as Outlook was "closing".
>>
>> Mark
>>
>> "Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
>> news:OQg99yEIFHA.1172@TK2MSFTNGP12.phx.gbl...
>>> What is the exact failing code? Do you check that the toolbar already
>>> exists?
>>>
>>> Dmitry Streblechenko (MVP)
>>> http://www.dimastr.com/
>>> OutlookSpy - Outlook, CDO
>>> and MAPI Developer Tool
>>>
>>> "Mark Smith" <its@online.nospam> wrote in message
>>> news:%235NtOfDIFHA.560@TK2MSFTNGP12.phx.gbl...
>>>> If Outlook doesn't close down completely (in my case, another add-in is
>>>> running that apparently doesn't release all of its resources properly)
>>>> and I "start" Outlook again, I get a NewExplorer event when the main
>>>> window pops up again. When I call Explorer::get_CommandBars so I can
>>>> add my command bar, it fails, with an HRESULT that appears to be
>>>> garbage, since it is different every time.
>>>>
>>>> I haven't tested this behavior with a NewExplorer event under normal
>>>> circumstances, because I don't know how to make one happen under normal
>>>> circumstances.
>>>>
>>>> The odd thing is that the add-in that is causing this problem doesn't
>>>> have any problem creating its own toolbar in this case.
>>>>
>>>> Can anybody help with this?
>>>>
>>>> Mark
>>>>
>>>
>>>
>>
>>
>
>

Looking at my own code, I usually try to handle the toolbars in the
NewExplorer event. If that fails, I also use Explorer::Active event - by
that time the explorer is fully initialized and visible.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Mark Smith" <its@online.nospam> wrote in message
news:ODJYDAPIFHA.3364@TK2MSFTNGP10.phx.gbl...
> Well, in OnStartupComplete I set up the NewExplorer event:
>
> STDMETHODIMP CAddin::OnStartupComplete(LPSAFEARRAY* custom)
> {
> // Check internal state
> if (m_pApplication == NULL)
> return E_FAIL;
>
> . . .
>
> hr = m_pApplication->get_Explorers(&m_pExplorers);
> if (FAILED(hr) || m_pExplorers == NULL) {
> char pBuf[256];
> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT %d\n
> Location: 4", hr);
> errorBox(pBuf);
> }
> else {
> hr = IDispEventSimpleImpl<4, CAddin,
> &__uuidof(Outlook::ExplorersEvents)>:ispEventAdvise(static_cast<IDispatch*>(m_pExplorers),
> &DIID_ExplorersEvents);
> if (FAILED(hr)) {
> char pBuf[256];
> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT %d\n
> Location: 5", hr);
> errorBox(pBuf);
> }
> else {
> m_bReleaseExplorersEvents = true;
> }
> }
>
> return S_OK;
> }
>
> The NewExplorer event creates a newToolBar, which wraps up the command bar
> and event handling code:
>
> void __stdcall CAddin::NewExplorer(IDispatch* _pdispExplorer)
> {
> // Add tool bar
> addToolBar(new ToolBar(CComQIPtr<Outlook::_Explorer>(_pdispExplorer),
> this));
> }
>
> The addToolBar function adds to thw list of toolbars:
>
> HRESULT CAddin::addToolBar(ToolBar* _pToolBar)
> {
> // Check input
> if (_pToolBar == NULL) {
> errorBox("Unable to add tool bar to window\n Cause: Out of memory\n
> Location: 1");
> return E_FAIL;
> }
> const HRESULT hr = _pToolBar->getResult();
> if (FAILED(hr)) {
> delete _pToolBar;
> return hr;
> }
>
> // Allocate list memory
> void* const pBuffer = realloc(m_ppToolBars, (m_NumToolBars + 1) *
> sizeof(ToolBar*));
> if (pBuffer == NULL) {
> delete _pToolBar;
> errorBox("Unable to add tool bar to window\n Cause: Out of memory\n
> Location: 2");
> return E_FAIL;
> }
>
> // Add tool bar
> m_ppToolBars = static_cast<ToolBar**>(pBuffer);
> m_ppToolBars[m_NumToolBars++] = _pToolBar;
> return S_OK;
> }
>
> Then the ToolBar constructor calls addToolBar to actually create the new
> toolbar and button:
>
> ToolBar::ToolBar(Outlook::_Explorer* _pExplorer, CAddin* _pParent)
> {
> if (_pExplorer == NULL) {
> ATLASSERT(_pExplorer);
> return;
> }
>
> m_Result = _pExplorer->get_CommandBars(&m_pCommandBars);
> if (FAILED(m_Result) || m_pCommandBars == NULL) {
> char pBuf[256];
> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT: %d\n
> Location: 1", m_Result);
> errorBox(pBuf);
> return;
> }
>
> m_Result = addToolBar();
> if (FAILED(m_Result) || m_pCommandBar == NULL) {
> char pBuf[256];
> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT: %d\n
> Location: 2", m_Result);
> errorBox(pBuf);
> return;
> }
> }
>
> addToolBar is not important for this case, since it is failing at
> get_CommandBars, before addToolBar even gets called.
>
> Mark
>
> "Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
> news:uOZrX4NIFHA.2784@TK2MSFTNGP09.phx.gbl...
>> So what is your code?
>>
>> Dmitry Streblechenko (MVP)
>> http://www.dimastr.com/
>> OutlookSpy - Outlook, CDO
>> and MAPI Developer Tool
>>
>> "Mark Smith" <its@online.nospam> wrote in message
>> news:%234KT8tMIFHA.2700@TK2MSFTNGP09.phx.gbl...
>>> Well, here are a few of the HRESULTs that I have
>>> gotten: -1733279739, -1594867707, -1456455675, -1318043643.
>>>
>>> I'm not sure what you mean by checking if the toolbar already exists.
>>> get_CommandBars is failing, so I can't check anything about the command
>>> bars. The original toolbar was removed when the Explorer OnClose event
>>> was received as Outlook was "closing".
>>>
>>> Mark
>>>
>>> "Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
>>> news:OQg99yEIFHA.1172@TK2MSFTNGP12.phx.gbl...
>>>> What is the exact failing code? Do you check that the toolbar already
>>>> exists?
>>>>
>>>> Dmitry Streblechenko (MVP)
>>>> http://www.dimastr.com/
>>>> OutlookSpy - Outlook, CDO
>>>> and MAPI Developer Tool
>>>>
>>>> "Mark Smith" <its@online.nospam> wrote in message
>>>> news:%235NtOfDIFHA.560@TK2MSFTNGP12.phx.gbl...
>>>>> If Outlook doesn't close down completely (in my case, another add-in
>>>>> is running that apparently doesn't release all of its resources
>>>>> properly) and I "start" Outlook again, I get a NewExplorer event when
>>>>> the main window pops up again. When I call Explorer::get_CommandBars
>>>>> so I can add my command bar, it fails, with an HRESULT that appears to
>>>>> be garbage, since it is different every time.
>>>>>
>>>>> I haven't tested this behavior with a NewExplorer event under normal
>>>>> circumstances, because I don't know how to make one happen under
>>>>> normal circumstances.
>>>>>
>>>>> The odd thing is that the add-in that is causing this problem doesn't
>>>>> have any problem creating its own toolbar in this case.
>>>>>
>>>>> Can anybody help with this?
>>>>>
>>>>> Mark
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

That did the trick. Thanks for your help!

Mark

"Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
news:uVUXTNQIFHA.720@TK2MSFTNGP10.phx.gbl...
> Looking at my own code, I usually try to handle the toolbars in the
> NewExplorer event. If that fails, I also use Explorer::Active event - by
> that time the explorer is fully initialized and visible.
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool
>
> "Mark Smith" <its@online.nospam> wrote in message
> news:ODJYDAPIFHA.3364@TK2MSFTNGP10.phx.gbl...
>> Well, in OnStartupComplete I set up the NewExplorer event:
>>
>> STDMETHODIMP CAddin::OnStartupComplete(LPSAFEARRAY* custom)
>> {
>> // Check internal state
>> if (m_pApplication == NULL)
>> return E_FAIL;
>>
>> . . .
>>
>> hr = m_pApplication->get_Explorers(&m_pExplorers);
>> if (FAILED(hr) || m_pExplorers == NULL) {
>> char pBuf[256];
>> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT %d\n
>> Location: 4", hr);
>> errorBox(pBuf);
>> }
>> else {
>> hr = IDispEventSimpleImpl<4, CAddin,
>> &__uuidof(Outlook::ExplorersEvents)>:ispEventAdvise(static_cast<IDispatch*>(m_pExplorers),
>> &DIID_ExplorersEvents);
>> if (FAILED(hr)) {
>> char pBuf[256];
>> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT %d\n
>> Location: 5", hr);
>> errorBox(pBuf);
>> }
>> else {
>> m_bReleaseExplorersEvents = true;
>> }
>> }
>>
>> return S_OK;
>> }
>>
>> The NewExplorer event creates a newToolBar, which wraps up the command
>> bar and event handling code:
>>
>> void __stdcall CAddin::NewExplorer(IDispatch* _pdispExplorer)
>> {
>> // Add tool bar
>> addToolBar(new ToolBar(CComQIPtr<Outlook::_Explorer>(_pdispExplorer),
>> this));
>> }
>>
>> The addToolBar function adds to thw list of toolbars:
>>
>> HRESULT CAddin::addToolBar(ToolBar* _pToolBar)
>> {
>> // Check input
>> if (_pToolBar == NULL) {
>> errorBox("Unable to add tool bar to window\n Cause: Out of
>> memory\n Location: 1");
>> return E_FAIL;
>> }
>> const HRESULT hr = _pToolBar->getResult();
>> if (FAILED(hr)) {
>> delete _pToolBar;
>> return hr;
>> }
>>
>> // Allocate list memory
>> void* const pBuffer = realloc(m_ppToolBars, (m_NumToolBars + 1) *
>> sizeof(ToolBar*));
>> if (pBuffer == NULL) {
>> delete _pToolBar;
>> errorBox("Unable to add tool bar to window\n Cause: Out of
>> memory\n Location: 2");
>> return E_FAIL;
>> }
>>
>> // Add tool bar
>> m_ppToolBars = static_cast<ToolBar**>(pBuffer);
>> m_ppToolBars[m_NumToolBars++] = _pToolBar;
>> return S_OK;
>> }
>>
>> Then the ToolBar constructor calls addToolBar to actually create the new
>> toolbar and button:
>>
>> ToolBar::ToolBar(Outlook::_Explorer* _pExplorer, CAddin* _pParent)
>> {
>> if (_pExplorer == NULL) {
>> ATLASSERT(_pExplorer);
>> return;
>> }
>>
>> m_Result = _pExplorer->get_CommandBars(&m_pCommandBars);
>> if (FAILED(m_Result) || m_pCommandBars == NULL) {
>> char pBuf[256];
>> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT: %d\n
>> Location: 1", m_Result);
>> errorBox(pBuf);
>> return;
>> }
>>
>> m_Result = addToolBar();
>> if (FAILED(m_Result) || m_pCommandBar == NULL) {
>> char pBuf[256];
>> sprintf(pBuf, "Unable to add tool bar to window\n HRESULT: %d\n
>> Location: 2", m_Result);
>> errorBox(pBuf);
>> return;
>> }
>> }
>>
>> addToolBar is not important for this case, since it is failing at
>> get_CommandBars, before addToolBar even gets called.
>>
>> Mark
>>
>> "Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
>> news:uOZrX4NIFHA.2784@TK2MSFTNGP09.phx.gbl...
>>> So what is your code?
>>>
>>> Dmitry Streblechenko (MVP)
>>> http://www.dimastr.com/
>>> OutlookSpy - Outlook, CDO
>>> and MAPI Developer Tool
>>>
>>> "Mark Smith" <its@online.nospam> wrote in message
>>> news:%234KT8tMIFHA.2700@TK2MSFTNGP09.phx.gbl...
>>>> Well, here are a few of the HRESULTs that I have
>>>> gotten: -1733279739, -1594867707, -1456455675, -1318043643.
>>>>
>>>> I'm not sure what you mean by checking if the toolbar already exists.
>>>> get_CommandBars is failing, so I can't check anything about the command
>>>> bars. The original toolbar was removed when the Explorer OnClose event
>>>> was received as Outlook was "closing".
>>>>
>>>> Mark
>>>>
>>>> "Dmitry Streblechenko" <dmitry@dimastr.com> wrote in message
>>>> news:OQg99yEIFHA.1172@TK2MSFTNGP12.phx.gbl...
>>>>> What is the exact failing code? Do you check that the toolbar already
>>>>> exists?
>>>>>
>>>>> Dmitry Streblechenko (MVP)
>>>>> http://www.dimastr.com/
>>>>> OutlookSpy - Outlook, CDO
>>>>> and MAPI Developer Tool
>>>>>
>>>>> "Mark Smith" <its@online.nospam> wrote in message
>>>>> news:%235NtOfDIFHA.560@TK2MSFTNGP12.phx.gbl...
>>>>>> If Outlook doesn't close down completely (in my case, another add-in
>>>>>> is running that apparently doesn't release all of its resources
>>>>>> properly) and I "start" Outlook again, I get a NewExplorer event when
>>>>>> the main window pops up again. When I call Explorer::get_CommandBars
>>>>>> so I can add my command bar, it fails, with an HRESULT that appears
>>>>>> to be garbage, since it is different every time.
>>>>>>
>>>>>> I haven't tested this behavior with a NewExplorer event under normal
>>>>>> circumstances, because I don't know how to make one happen under
>>>>>> normal circumstances.
>>>>>>
>>>>>> The odd thing is that the add-in that is causing this problem doesn't
>>>>>> have any problem creating its own toolbar in this case.
>>>>>>
>>>>>> Can anybody help with this?
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>