VSTO - Outlook AddIn and ContactItem

Hello all, bear with me if posting in incorrect forum.

I've created an Outlook AddIn, using VSTO 2005 (not SE) against Outlook 2003. My Add-In is nearly working as intended, but I have a small issue. The purpose of addin is to add functionality to format contact items by rules I configure in a Dialog. (I.e. change FileAs, Email1DisplayName, Email3DisplayName, Email3DisplayName and all kind of phonenumbers in contact items)

This contact formating can be done from:

1) button added in a custom Toolbar in Explorer(s). Then all contacts in selected folder is formated and SAVED

2) button added to the standard toolbar inside the Contact Inspector. Formating is then done on ContactItem presented in the Inspector. My code don't save here after formatting ... leaving that decision to the user when closing inspector.

Scenario: I open an existing ContactItem. Then I use my format button inside Inspector, which performs the formatting nice and as planed. The formatting is also seen inside inspector. All good so far. Then I close inspector, WITHOUT SAVING (I get the question about "Do you want to save changes ", but I answer No)

Problem: When I now open this particular Contact Item again, I SEE my last (unsaved) formatting. If I exit Inspector at once, without further changes in item, I'm again asked: "Do You want to save changes ¡± Strange! However, in the Explorer showing all contact items, I DON'T see these (unsaved) formatting. If I exit Outlook and reopen, the contact item is back on track (i.e.: showing as it was BEFORE last formatting)

So: Any ideas

Jan Inge

X4U wrote:

Hello Jan, I asume that you have used an InspectorWrapper class for this. As soon as the Inspector.Close event has fired you should do: _ContactItem = null; _Inspector = null; GC.Collect(); GC.WaitForPendingFinalizers(); This hard-release should help here. Greets, Helmut

Thx for replying Helmut . Yes I have the InspectorWrapper ... used exact that classname too and also already have those two private members in the wrapper ... spooky

I'll try it, but this lead to 2 new questions:

1) Isn't it "dangerous" to call GC.WaitForPendingFinalizers .. infinite loop

2) I guess that my existing OnInspectorClose event should perform your code as the very last thing

Jan Inge

X4U wrote:

Hello Jan, .... Greets, Helmut

It's kind of fun that You answer my thread Helmut. Last week I've spent a lot of time investigating this Add-In technology (new to me). And of cource, when googling about the theme, Your name came up a lot

So, since You're already in this thread Helmut, I like to pop in another more important question. The above problem I get into when developing for fun at home, but the very reason for investigating and developing Add-In is a particular bug I try to solve at job. (I'm a consultant, performing a bugfix in an Add-In written by others some time ago.)

I think I've found the solution by reading Your stuff at x4u and stuff in Eric Carters blog, but I like to have Your opinion:

Problem: The existing code throw an exception when trying to execute codeline like:

inspectors.NewInspector += new Outlook.InspectorsEvents_NewInspectorEventHandler(OnNewInspector);

System.Runtime.InteropServices.InvalidComObjectException: COM object that has been separated from its underlying RCW cannot be used.
at System.Runtime.InteropServices.UCOMIConnectionPoint.Advise(Object pUnkSink, Int32& pdwCookie)
at Microsoft.Office.Interop.Outlook.InspectorsEvents_EventProvider.add_NewInspector(InspectorsEvents_NewInspectorEventHandler )
at Microsoft.Office.Interop.Outlook.InspectorsClass.add_NewInspector(InspectorsEvents_NewInspectorEventHandler )

The Add-In was originaly developed as a Shared Add-In, implementing the Extensibility.IDTExtensibility2 interface. Later the Add-In was ported (rewritten) to be a VSTO Add-In for Outlook. I think that the "porting" was poor, and the code was not reviewed with "VSTO-eyes" ... if You understand

My theory: The Add-In code performs call to ReleaseComObject, and in my understanding there is no need to call ReleaseComObject in a VSTO Add-In ... or even, it can be "dangerous" if doing it incorrect. So, when seeing that stack, and knowing that code perform ReleaseComObject, my solution will be to remove ReleaseComObject-calls, and let GC do the job ..... I've created the new Add-In with such fix, going to let the customer test it tomorrow

What do You think Helmut Hope to hear from You ....

Rgds

Jan Inge

X4U wrote:

Hello Jan, ..... Have a look for COM Objects passed by ref and the Released. If you pass it by ref - don't release or set to null If you don't pass it by ref set it to null (no ReleaseCOMObject) and do the GC stuff. Greets, Helmut

I'll look into that tomorrow.

But for future knowledge, is there a rule of thumb when you must use ReleaseComObject in Outlook Add-In Ref: shahine.com/omar and my earlier link to Carters blog

BTW: You solution in second post worked like a sharm Thx!!

Rgds

Jan Inge