Access Violation when closing Send To window

[Matt Fletcher]

I'm trying to prevent my add-in causing an access violation in MSMAPI32 at
3552fe50. This occurs when an Outlook Window which was generated from Send
To->Mail Recipient (on an explorer/desktop context menu) is closed. The
problem occurs in Windows 2000 and Windows 98, but not in Windows XP.

The trap appears to be caused by sinking ItemEvents from a MailItemPtr which
is itself derived from the Inspector associated with a "Send To" Outlook
window.

I have reproduced this problem using a test add-in: all it does is start a
thread which sits in a loop waiting for an Application::Inspector to give me
an InspectorPtr - when it does I call GetCurrentItem and sink the events.
Sample code below - stripped of error handling and tracing for brevity. (I
realise this is an unsophisticated way to get hold of the MailItem, but it
gets round the lack of a NewInspector event).

Any help with this particular brick wall greatly appreciated!

Matt Fletcher


STDMETHODIMP CConnect::OnConnection(IDispatch *pApplication,
AddInDesignerObjects::ext_ConnectMode
ConnectMode,
IDispatch *pAddInInst,
SAFEARRAY ** /*custom*/ )
{
m_spOutlookApplication = (_ApplicationPtr)pApplication;
return S_OK;
}

STDMETHODIMP CConnect::OnStartupComplete (SAFEARRAY ** /*custom*/ )
{
DWORD dwID;
::CreateThread(NULL, 0, SendToHandlerProc, (LPVOID)this, 0, &dwID);
return S_OK;
}

void CConnect::AttachToMessage()
{
if (!m_bAttached)
{
_InspectorPtr spInspector =
m_spOutlookApplication->ActiveInspector();
if (spInspector)
{
m_spMailItem = spInspector->GetCurrentItem();
if (m_spMailItem)
{
MailItemEventsImpl:ispEventAdvise(m_spMailItem);
m_bAttached = true;
}
}
}
}

DWORD WINAPI CConnect::SendToHandlerProc(LPVOID lpParameter)
{
CConnect * pConnect = (CConnect *)lpParameter;
while (!m_bAttached)
{
pConnect->AttachToMessage();
::Sleep(500);
}

return 0;
}

STDMETHODIMP_(void) CConnect::OnItemClose(VARIANT_BOOL * Cancel)
{
MessageBox(NULL, "OnItemClose", "Debug", MB_OK);

if (m_spMailItem)
MailItemEventsImpl:ispEventUnadvise(m_spMailItem);

m_spMailItem = 0;
m_spOutlookApplication = 0;
}

 

[Thomas Wetzel]

Hello Matt,

what Outlook version?

Thomas Wetzel

 

[Matt Fletcher]

I've reproduced the problem using Outlook XP (build 10.4219.4219) on Windows
2000 and Outlook 2000 (build 9.0.0.3821) on Windows 98 (in a Virtual
Machine). I haven't systematically tested different versions/builds of
Outlook on different operating systems.

 

[Matt Fletcher]

Oh, and I should have added that the trap occurs in explorer, rather than
the Outlook process.