Outlook shutdown bug

  • Thread starter Thread starter Sankalp
  • Start date Start date
S

Sankalp

Hello,
Under certain circumstances, after an outlook add-in is installed,
closing outlook results in the UI being closed. But in the Task Manager, we
can still see the OUTLOOK.exe alive.

How does one shutdown outlook cleanly. The KB on the MS site gives
sample in VB. How can this be done with VC++?

Can any sample or a link to a sample be provided?

Thanks,
Sankalp
 
Make sure you don't have hangling references to the Outlook objects.
Are you keeping any Outlook objects referenced in the global/class
variables?

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

1. There is just one Outlook::Application object, following is what it looks
like

public:
IDispatch *gApplication;

STDMETHOD(OnConnection)(IDispatch * Application, ext_ConnectMode
ConnectMode, IDispatch * AddInInst, SAFEARRAY * * custom)
{
...
gApplication = Application;
....
}

STDMETHOD(OnDisconnection)(ext_DisconnectMode RemoveMode, SAFEARRAY * *
custom)
{
...
CComQIPtr <Outlook::_Application> pApp(gApplication);
pApp.Release();
pApp = NULL;
....
}


2. Am using CComPtr on the Outlook objects, can I assume they get released
properly since we are using the smart pointer?

Thanks,
Sankalp
 
According to posted code see comments below

--
WBR
Henry


Sankalp said:
Hi,

1. There is just one Outlook::Application object, following is what it looks
like

public:
IDispatch *gApplication;

STDMETHOD(OnConnection)(IDispatch * Application, ext_ConnectMode
ConnectMode, IDispatch * AddInInst, SAFEARRAY * * custom)
{
...
gApplication = Application;
That code does not call AddRef for Application
....
}

STDMETHOD(OnDisconnection)(ext_DisconnectMode RemoveMode, SAFEARRAY * *
custom)
{
...
That code calls QueryInterface so it AddRef gApplication object
CComQIPtr <Outlook::_Application> pApp(gApplication); And release queried interface
pApp.Release(); That does nothing
pApp = NULL;
....
}


2. Am using CComPtr on the Outlook objects, can I assume they get released
properly since we are using the smart pointer?

So you neither addref Application in Connect nor Release it in the disconnect


use smart pointers like this:

public:
CComQIPtr <Outlook::_Application> gApplication;

STDMETHOD(OnConnection)(IDispatch * Application, ext_ConnectMode
ConnectMode, IDispatch * AddInInst, SAFEARRAY * * custom)
{
...
gApplication = Application;
....
}

STDMETHOD(OnDisconnection)(ext_DisconnectMode RemoveMode, SAFEARRAY * *
custom)
{
...
gApplication = NULL;
....
}


Make sure that you released all object obtained via gApplication object.
 
Hi Henry,
Thank you very much for pointing that out.

So, by setting all the Outlook object references to NULL, I presume
outlook will shutdown cleanly?

This is not consistant across m/c or platforms, is there any way to
produce this bug consistantly?

Thanks and regards,
Sankalp
 
See some tips

some method or property returns IDispatch* pointer and you are using
TypedSmart pointer after retrieving pointer.

//just some simple sample
IDispatch* lpObject = NULL;

//AddRef object internaly
obj->get_Object(&lpObject);

//AddRef object by Querying requested interface
CComQIPtr<SomeInterface> smartPointer = lpObject;

//So to properly clead up you need
smartPointer = NULL;
lpObject->Release();

or you should use some thing like

//just some simple sample
CComQIPtr<IDispatch> lpObject;

//AddRef object internaly
obj->get_Object(&lpObject);

//AddRef object by Querying requested interface
CComQIPtr<SomeInterface> smartPointer = lpObject;

//So to properly clead up you need
smartPointer = NULL;
lpObject = NULL;


Anoter more tricky sample:

//obj->get_Object returns IDispatch*
CComQIPtr<SomeInterface> smartPointer = obj->get_Object();

in this case you definitely have ref leak. Because object is AddRefed twice
but smart pointer will Release it only once.
 
Henry,
Thank you very much.
Really good snippet to understand the intricacies of releasing
references.
Thanks and regards,
Sankalp
 
Back
Top