none
C# + Outlook 2010 + Determine if close event happened on AppointmentItem object in write event RRS feed

  • Question

  • Hello Techies,

    I have a situation where I need to update AppointmentItem category and would like to know how I can handle this properly in below use case.

    Use case:

    1. Open existing appointment, invite attendees

    2. Close window using (X) button on top right

    it gives below Outlook prompt

    To close the meeting, choose from the following options:

    - Save changes and send meeting

    - Save changes but don't send

    - Don't save changes

    OK / Cancel

    Events occur:

    Currently in my code below events are already hooked for appointment item and occur in below sequence if we chose option "Save changes but don't send":

    Close event

    Write event

    AfterWrite event

    Now I want to update category after some code logic in AfterWrite, but that's not possible as we cannot access any item properties within that event.

    I cannot update category directly in Close event as it would be too early to update it, as user might cancel the whole operation.

    So I am thinking of updating category in Write event, and so want to know how i can determine if close event occurred before write event.

    One way i can think of achieving this is to set some global flag and set it in close event and check it in write event, but does Outlook provide any better way for this?

    Thanks for your attention.


    sureshh...

    Thursday, January 26, 2017 8:27 PM

Answers

  • Yes, I did just that in a few projects. Do not use a global flag since you can have multiple appointments open - you probably need a object wrapping each appointment/inspector anyway, so you can introduce a boolean prop on that wrapper class.

    You can also delay running your code until after AfterWrite event fires. You can do that easily by enabling a timer in the AfterWrite event handler, then run you code in the timer event since you will be out of the AfterWrite event. Use the Timer object from the Forms namespace - unlike the Timer object from the System namespace, it fires on the same thread where it was created instead of a secondary thread (where you cannot use Outlook objects).


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

    Thursday, January 26, 2017 8:47 PM

All replies

  • Yes, I did just that in a few projects. Do not use a global flag since you can have multiple appointments open - you probably need a object wrapping each appointment/inspector anyway, so you can introduce a boolean prop on that wrapper class.

    You can also delay running your code until after AfterWrite event fires. You can do that easily by enabling a timer in the AfterWrite event handler, then run you code in the timer event since you will be out of the AfterWrite event. Use the Timer object from the Forms namespace - unlike the Timer object from the System namespace, it fires on the same thread where it was created instead of a secondary thread (where you cannot use Outlook objects).


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

    Thursday, January 26, 2017 8:47 PM
  • Thanks Dmitry. Yes I thought of timer approach too, but then thought it might cause some unknown issues. Also I learnt since Outlook is STA based product, we should not use background thread etc. Isn't it correct?

    sureshh...

    Thursday, January 26, 2017 9:26 PM
  • Correct. That is why you need to use the Times class from the Forms namespace - it fires on the main thread.

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

    Friday, January 27, 2017 1:37 PM
  • And since you are suggesting I suppose its advised and safe approach with Outlook plugin developments?

    sureshh...

    Monday, January 30, 2017 11:45 PM
  • Yes, I am advising it. And it was safe in all my projects.


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

    Monday, January 30, 2017 11:50 PM
  • Ok great. I will try it out. Just one thing - how about performance with this approach, do you see anything that I need to take care with this implementation, maybe not running timer for long time?

    sureshh...

    Monday, January 30, 2017 11:54 PM
  • NO performance issues. Just make sure the timer delay is minimal - all you need to do is be outside of the event handler.

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

    Tuesday, January 31, 2017 12:00 AM
  • Thanks Dmitry for quick response. Got it. I will try this out and confirm if it works in my case too.

    sureshh...

    Tuesday, January 31, 2017 12:02 AM
  • Hi sureshh,

    if you got the answer of your question then please mark the suggestion given by Dmitry Streblechenko _MVP_ as an answer.

    so that we can close this thread.

    Regards

    Deepak


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, January 31, 2017 2:26 AM
    Moderator
  • Thanks Dmitry for your advise. I tried this solution and it worked in my case too. Next I will get this tested with our QA/Perf teams.

    sureshh...

    Tuesday, January 31, 2017 9:38 PM