none
Make task befor send mail. Use of "Show Progress" and Exception RRS feed

  • Question

  • Hello,

    Could I handle Send Event of MailItem in a way that Outlook understand it.

    I want to do a long task before sending the mail. The user musn't be block. I wish Outlook display the task when user click on "Show progress" I have two choise actualy:

    - I cancel upload while my task ending.

    - I make a new thread were i do all the process and finally call the mailItem send method


    The first seems to work pretty well. But it need the user wait to the end of the process before send. As it didn't block the user to write read others mail it could be a solution.

    I prefered the second one who don't change the user experience. But i have many problem to do it :

    - How to apeared in "Show progress"

    - Exception raise when i send a (draft)mailItem show in preview pane.

    Thanks.

    Thursday, April 23, 2015 12:48 PM

Answers

  • That is how Outlook Object Model works. Prior to Outlook 2013, some things would work on secondary threads, but sometimes they would blow up in a really spectacular fashion. So in Outlook 2013 Microsoft made a decision to raise an exception immediately as soon as Outlook detects that one of its objects is used on a thread other than the primary Outlook thread.

    This applies to the COM addins only of course since when your code is running inside the outlook.exe process. If you are out-of-proc, all calls will be marshaled to the main Outlook thread anyway, which negates the whole purpose of using multiple threads to begin with.

    Only Extended MAPI (C++ or Delphi) can be safely used on a secondary thread. You can also use the RDO family of objects in Redemption - it wraps Extended MAPI and can be safely used on a secondary thread from any language. See also http://www.dimastr.com/redemption/faq.htm#Threads


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    • Marked as answer by L.HlModerator Wednesday, April 29, 2015 2:19 AM
    Thursday, April 23, 2015 3:18 PM

All replies

  • Hello,

    The ItemSend event of the Application class allows to cancel any further processing setting the Cancel parameter to true. For example, you may start a new thread for a long-running task and cancel the process of sending the email. To update the Outlook UI (it can be a progress bar shown anywhere to a user) you can use the BackgroundWorker component which provides a convenient way - all the required events for that. See Walkthrough: Multithreading with the BackgroundWorker Component (C# and Visual Basic) for more information. And when long running tasks are done you may call the Send method anew. Be aware, you most probably will need to add a user property to distinguish processed and non-processed Outlook items. 

    Thursday, April 23, 2015 1:07 PM
  • In fact i forget to wrote before. My main problem with the second one is to handle Application.Quit event. Since actual version of Outlook let you a define timer to do the process i can't block the case where user quit Outlook without waiting the mail to be send.

    It's a big issue to me since i have many time before send mail (whithout the add-in) and quit Outlook and notice the urgent mail wasn't send. But the mail was send when i reopen Outlook. Since it happen to me every time i send a mail. I think it's also gonna be the case of my addIn end-user.

    So i want the more seem-like interface as addIn-less Outlook. If i could avoid loose user with new thinks of my own.

    Thursday, April 23, 2015 2:06 PM
  • i can't block the case where user quit Outlook without waiting the mail to be send.

    You need to warn the end user that a task in the progress at the moment and ask for continue without closing Outlook or stop all background work and close Outlook. 

    What if the end user shuts down the machine? How are you going to handle such cases? :)

    Thursday, April 23, 2015 2:19 PM
  • Make sure you do not touch any Outlook Object Model objects on that secondary thread.

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Thursday, April 23, 2015 2:38 PM
  • The questions is not related to the OOM and secondary threads. It is about architectural decisions. 
    Thursday, April 23, 2015 2:42 PM
  • => What if the end user shuts down the machine? How are you going to handle such cases? :)

    I don't know.

    I seen now how complex and riskful it's to do this way. Microsoft themself didn't manage it correctly. In a first time i thinks block the user is more correct than do thinks without him having control or knowledge of what happen.

    And if in the second time i'll find a way to handle the situation i'll try it and post it here. Thanks.
    Thursday, April 23, 2015 2:57 PM
  • Dmitry Streblechenko _MVP_=>Make sure you do not touch any Outlook Object Model objects on that secondary thread.

    Why?

    • Edited by Aurelien312 Thursday, April 23, 2015 3:03 PM
    Thursday, April 23, 2015 2:58 PM
  • I didn't notice anything in the initial post about that.

    Anyway, in case if you didn't know, Outlook/Office applications uses the single threaded apartment model. Old versions marshal your calls from secondary threads on the main one. But Outlook 2013 throws exceptions in that case. 

    You may consider using a low-level API on which Outlook is based on - Extended MAPI. Or any other third-party wrapper around that API such as Redemption. Extended MAPI can be used on secondary threads.


    Thursday, April 23, 2015 3:07 PM
  • That is how Outlook Object Model works. Prior to Outlook 2013, some things would work on secondary threads, but sometimes they would blow up in a really spectacular fashion. So in Outlook 2013 Microsoft made a decision to raise an exception immediately as soon as Outlook detects that one of its objects is used on a thread other than the primary Outlook thread.

    This applies to the COM addins only of course since when your code is running inside the outlook.exe process. If you are out-of-proc, all calls will be marshaled to the main Outlook thread anyway, which negates the whole purpose of using multiple threads to begin with.

    Only Extended MAPI (C++ or Delphi) can be safely used on a secondary thread. You can also use the RDO family of objects in Redemption - it wraps Extended MAPI and can be safely used on a secondary thread from any language. See also http://www.dimastr.com/redemption/faq.htm#Threads


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    • Marked as answer by L.HlModerator Wednesday, April 29, 2015 2:19 AM
    Thursday, April 23, 2015 3:18 PM