none
Outlook 2010 Add In with Form Region for Tasks not reloading the task each time the task is opened RRS feed

  • Question

  • Hi,
    I am having a problem with an Outlook 2010 Add In that uses a custom form region for tasks.  The problem is that the latest version of the task is not loaded each time the task is opened.
    Steps to reproduce the problem:
    1) Create Add In with Form Region as described in the lab here:  http://msdn.microsoft.com/en-us/gg621195.
    2) Create a task.  Save and close.
    3) Open the task again.  Make some changes in the custom fields.  Close the window.  When prompted to save choose 'No'.
    4) Open the task again.  - The changes that you said not to save are still there!
    5) Update the task using Outlook on another computer, then open the task again on the first computer.  - The changes you made on the other computer are not shown until you restart Outlook!
    If I disable the Add In then everything works as expected.  The latest version of the task is loaded each time I open the task.
    The reason why this is a problem is because my system is updating tasks in the Exchange Server using Exchange Web Services.  Users tend to leave Outlook open all day so they are never getting the updated tasks.
    My system also updates appointments and that works as expected.  If I update an appointment with Exchange Web Services, the changes are visible the next time I open the appointment in Outlook.  It seems to just be a problem with tasks.
    Is there something I can do in the Add In that will force Outlook to reload the task each time the task is opened?
    Things I have tried:
    I have tried disabling 'Cached Exchange Mode', but it didn't make any difference.
    I tried calling CType(Me.OutlookItem, TaskItem).close() in FormRegionClosed, but that makes Outlook crash.
    Many thanks for your help.
    Wednesday, February 1, 2012 1:51 PM

Answers

  • Hi,

    I appears that while this sample illustrates how to get the form region up and running, it unfortunately cuts some corners in terms of best practice implementation with the Outlook object model. I see two issues:

    1. The add-in will always dirty items that do not have the custom properties on them, so the user will be prompted to save the item even if they just open and close them. Typically this is not desireable.

    2. More importantly for your primary issue, the add-in doesn't clean up the references to the item and that is why you are seeing issues with having things update correctly. There is good info in coding with Outlook's object model in .Net here:

    http://blogs.msdn.com/b/mstehle/archive/tags/oom-net/

    In particular, see: http://blogs.msdn.com/b/mstehle/archive/2007/12/07/oom-net-part-2-outlook-item-leaks.aspx

    Again, I didn't test this extensively, but it seems the addin should have implemented the following to ensure that Outlook doesn't hold on to a reference to the task item after the user is done with it.

    using System.Runtime.InteropServices;
    
    ...
    
            private void BillableTaskRegion_FormRegionClosed(object sender, System.EventArgs e)
            {
                Marshal.ReleaseComObject(m_taskItem);
                m_taskItem = null;
            }


    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging

    • Marked as answer by Billy64532 Wednesday, February 8, 2012 1:43 PM
    Tuesday, February 7, 2012 7:40 PM

All replies

  • Hi Bill,

    Thanks for your post.

    You might be interesting in the information provided by Mike in this thread:

    http://social.msdn.microsoft.com/Forums/en-SG/vsto/thread/7cba8ea0-6147-4f74-8e62-42e5cf260ecf

    I hope this helps.


    Calvin Gao[MSFT]
    MSDN Community Support | Feedback to us
    Friday, February 3, 2012 6:04 AM
    Moderator
  • Hi Calvin,

     

    Thanks, for the reply.  I have read through that forum post and the support page mentioned.  However I think it is different to the problem I am experiencing.  The problem described is about creating custom properties in messages saved to a file or sent over the internet.  Specifically it says in the support page that the changes don't affect messages sent using Exchange.

     

    I don't have a problem creating the custom properties.  Its just getting the latest version of the task to load that is the problem.

     

    The confusing thing is that my solution has both custom appointments and tasks, and the appointments are working fine.  When I update an appointment in Exchange I get the changes in Outlook almost instantly.

     

    When I update a task in Exchange I see the 'Modified' date in the task list in Outlook is updated.  When I open the task, if it is the first time I have opened the task since starting Outlook, I get the latest version.  BUT, once a task has been opened in Outlook, opening it again always shows the same information regardless of whether it has been updated in Exchange, or you said not to save changes when closing it.

     

    It seems that Outlook is getting notified of the changes because the 'Modified' date is always updated.  Its just that it won't display the latest version until I restart Outlook.

     

    Friday, February 3, 2012 9:49 AM
  • Hi,

    I appears that while this sample illustrates how to get the form region up and running, it unfortunately cuts some corners in terms of best practice implementation with the Outlook object model. I see two issues:

    1. The add-in will always dirty items that do not have the custom properties on them, so the user will be prompted to save the item even if they just open and close them. Typically this is not desireable.

    2. More importantly for your primary issue, the add-in doesn't clean up the references to the item and that is why you are seeing issues with having things update correctly. There is good info in coding with Outlook's object model in .Net here:

    http://blogs.msdn.com/b/mstehle/archive/tags/oom-net/

    In particular, see: http://blogs.msdn.com/b/mstehle/archive/2007/12/07/oom-net-part-2-outlook-item-leaks.aspx

    Again, I didn't test this extensively, but it seems the addin should have implemented the following to ensure that Outlook doesn't hold on to a reference to the task item after the user is done with it.

    using System.Runtime.InteropServices;
    
    ...
    
            private void BillableTaskRegion_FormRegionClosed(object sender, System.EventArgs e)
            {
                Marshal.ReleaseComObject(m_taskItem);
                m_taskItem = null;
            }


    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging

    • Marked as answer by Billy64532 Wednesday, February 8, 2012 1:43 PM
    Tuesday, February 7, 2012 7:40 PM
  • Many thanks, thats exactly what I needed.  After ensuring that all COM objects are released it is now working.

    The blog post about item leaks was very interesting as well.  That was exactly the problem that I had.

    Wednesday, February 8, 2012 1:46 PM
  • Great, glad to hear that resolved this!

    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging

    Wednesday, February 15, 2012 3:58 PM