none
EMail created via API in Drafts Folder - Reverting?? RRS feed

  • Question

  • We've got a situation where we generate Outlook (desktop) emails via API calls (interop).  The emails are templated so magic strings are searched and appropriate values replace them from the calling app.  So far, so good.  Instead of doing a Send() on these, we currently do a Save() so the emails can be reviewed in the Drafts folder.  Here's where things get interesting...

    * Email generation is triggered via app

    * Email appears in Drafts

    * Draft email is opened.  Everything looks ok.  User opts not to send - but simply to close email.

    * Outlook prompts user to Save changes.  User thinks "I have made no changes" and clicks No.

    * Email reverts to template prior to string substitution - except that attachment added via API is still there.

    Thoughts?  It's almost as if it didn't Save().......

    Monday, February 3, 2020 3:51 PM

All replies

  • Hello,

    Firs off, check that the issue is reproducible with all other add-ins disabled. If this is caused by your add-in, release every COM object related to the email: the email itself, (Outlook.MailItem), its collections such as Attachments, UserProperties, etc., and every item you ever access in these collections.


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader

    Please mark answers and useful posts to help other developers use the forums efficiently.

    Tuesday, February 4, 2020 1:17 PM
  • I'm not creating an AddIn.  I have an external app generating the email via API calls.
    Thursday, February 6, 2020 6:34 PM
  • This doesn't really matter. You need to release COM objects.

    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader

    Please mark answers and useful posts to help other developers use the forums efficiently.

    Tuesday, February 18, 2020 6:51 AM
  • If you literally mean System.Runtime.InteropServices.Marshal.ReleaseComObject(someCOMObject)?  I've tried that, setting to null, etc...  EVERY instance of a COM object.

    Same symptoms.

    Is this a behavior you've seen before or are you just making sure I's are dotted and T's are crossed?  Ironically, no dot or cross in the capital letters...

    Tuesday, February 18, 2020 4:23 PM
  • The "reverting" thing resembles what I wrote on the Add-in Express blog here: "As a result, the user can see the item’s subject unchanged in the explorer window but, when the user opens it (the item) anew, the hidden inspector pops up with the e-mail subject still reflecting the changes that have just been canceled."

    I assume you do not have chains of Outlook calls such as {Application reference}.ActiveInspector().CurrentItem or {MailItem reference}.Attachments.Add() or {MailItem reference}.Attachments[i]. If you have them, all of them should be split so that get every COM object is stored in a separate variable. You will release the variable explicitly; the sooner you release it, the better. Don't store such variables globally; use them locally only.

    A call to an Office object model creates a COM object if that call returns an object (not a primitive type). There are rare exceptions to this rule. Off the top of my head I remember only one: see here.  

    Now, with no globally stored COM objects, with no chained calls, you need to replace all foreach loops on COM collections (such as Attachments) with for loops. 

    Now you need to release every COM object received through Outlook events.

    Finally, lets re-check typical sources of mistakes.

    I recently answered similar questions on an Add-in Express forum here. Also, Attachments.Add() returns a COM object; make sure you release it. Also you do not have an IF checking if (mailItem.Attachents != null && mailItem.Attachments.Count>0); all such calls create new COM objects (even though they represent the same collection of attachments on the same item).

    If nothing helps, use the contact form on the bottom of the Support page on Add-in-express.com to send me your source code with no business logic and sensitive info. The code may not be compilable. C#or VB.NET. 

    Ah, this may be caused by another add-in: turn off *all* of them first.


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader

    Please mark answers and useful posts to help other developers use the forums efficiently.

    Tuesday, February 18, 2020 9:15 PM