locked
Handling events fired for multiple instances of the same item RRS feed

  • Question

  • Does anyone have an effective technique to handle the same event being fired for an item when there are multiple instantiated instances of that item (for Outlook 2010)?

    Specifically, I capture the Reply and Reply All item events so that some checks can be done on the the original item and then make some changes to the reply Response item before it is displayed to the user. To do this I use both Explorer and Inspector wrappers to track the currently selected and opened items. I also detect the Application context menu event to detect if an item has been right clicked. This allows me to maintain a list of instantiated Outlook Items that might raise the Reply (/All) event.

    Typically this works well. The only problem is when there are multiple instances of the same item stored in my wrappers. Eg, the same item is selected in the Explorer window and opened in an Inspector and a user right clicks on the email and selects Reply. In this case the event handler is called three times (one for each item instance) with the same instance of the Response item.

    Currently, to prevent the Response item from being modified multiple times, I add a Custom Property field to the Response item in the Reply handler. Subsequent calls to the handler check for this property and abort if it has already been set.

    This seems to work but also seems like a real hack to me - does anyone have a more elegant and stateful solution (rather than actually modifying the item itself)?


    same
    Saturday, February 25, 2012 11:00 AM

All replies

  • Hello,

    > Eg, the same item is selected in the Explorer window and opened in an Inspector and a user right clicks on the email and selects Reply.

    Because you know the way the user presses Reply, you can identify which of the wrappers should be involved.

    I've published these blogs on detecting the Reply event:

    I don't use wrappers. Instead, I permanently tracks the active window and connect/reconnect to events of the item(s) which can be replied in a given moment: if you activate the inspector, then you can't reply an email selected in an explorer.


    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.

    Saturday, February 25, 2012 11:28 AM
  • Hi Andrei, thanks for the reply. Yes, I had already read all your above posts thoroughly and found them very useful in designing this very solution. I noticed how you dynamically connect events to only a single item at any one time but wasn't sure how specific your solution was to Addin Express (which I don't have).

    Also, to do it like you say (track the active window) I can't see how it can be done without some sort of wrapping. Eg the Explorer.SelectionChange event will only fire if the Explorer is instantiated so you need to keep a wrapper of Explorers to track this event and associate it with the Explorer on which it was raised. Also an Inspector wrapper seems to be the only way of tracking the active Inspector through the Inspector.Activate event. (It seems in ADX that these wrappers sort of come for free...?)

    Still, I suppose I could keep the wrappers to track the events that allow me to determine the only item which can currently be replied to. That way I would only connect events to a single item and would not have multiple events raised. Is this what you mean?

    Saturday, February 25, 2012 12:55 PM
  • Hi Hamish,

    You are correct: Add-in Express maintains wrappers for you. Still, this isn't a breakthrough, this is just a technical-level benefit. An explorer wrapper allows you to handle explorer-level events; Add-in Express hides the wrappers and makes the events accessible via an Outlook Events comonent. That is, the solution described on the blogs is NOT specific to Add-in Express.

    > Still, I suppose I could keep the wrappers to track the events that allow me to determine the only item which can currently be replied to. That way I would only connect events to a single item and would not have multiple events raised. Is this what you mean?

    Yes, exactly.


    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.

    Monday, February 27, 2012 8:58 AM
  • Thanks Andrei, understood. Appreciate the help so far.

    I think your approach is a better solution and I've managed to implement most it successfully. However I've come up against an issue with tracking the ItemContextMenu item. If the user chooses Reply from the context menu, both the ContextMenuClose and Explorer.Activate events fire BEFORE the Item.Reply event is raised. So I can't disconnect events from the Context item in case the user has selected Reply - if I do disconnect then the reply event is not raised. However if the user hasn't selected Reply, then I haven't connected back to the active Explorer.Selection item.

    One solution is to force the selection of the item when it is right-clicked but I don't want to change this behaviour for the users.

    Do you have any ideas?

    Cheers,

    Hamish

    Monday, February 27, 2012 12:31 PM
  • What Outlook version are you testing?

    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.

    Monday, February 27, 2012 12:40 PM
  • Outlook 2010
    Monday, February 27, 2012 1:50 PM
  • I'll try to test this tomorrow. Please make sure that you have Office 2010 SP1 installed. Is this Outlook 32-bit or 64-bit?

    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.

    Monday, February 27, 2012 2:59 PM
  • Thanks Andrei, looking forward to hearing from you.

    32-bit Outlook with SP1

    Outlook version is Microsoft Outlook 2010 (14.0.6109.5005) SP1 MSO (14.0.6112.5000)

    Windows 7 64-bit if that makes any difference.

    Monday, February 27, 2012 3:26 PM
  • Hamish,

    It was a terrible bug in my code. To make it work in Outlook 2010, I had to do the following:

    1. stop handling ItemContextMenuDisplay
    2. stop handling ContextMenuClose
    3. handle the Ribbon command IdMso="Reply"

    The code for the last item is this:

    private void ribbonCommandReply_OnAction(object sender, IRibbonControl control, bool pressed, ADXCancelEventArgs e)
    {
        Debug.Print("The Reply button is clicked.");
        object context = control.Context;
        if (context is Outlook.Selection)
        {
            Outlook.Selection selection = control.Context as Outlook.Selection;
            ConnectToSelectedItem(selection);
        }
        Marshal.ReleaseComObject(context);
    }

    The ADXRibbonCommand component used in the code above is meant to simplify the use of the Ribbon feature described in Temporarily Repurpose Commands on the Office Fluent Ribbon.

    Later this week, I'll update the blog. Thank you!


    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 28, 2012 3:20 PM
  • Andrei,

    I've now implemented an onAction handler for the idMso="Reply" and idMso="ReplyAll" command events on the Ribbon. However I still have two problems:

    1. I'm not able to determine the item that was right-clicked in the case of the command being raised via a context menu. In my case, control.Context is an Explorer object, not an Outlook.Slection object which your code above uses. So I can't tell the difference between the Reply command being clicked on the Explorer ribbon or through the Item context menu. Even if I could, I still couldn't then determine the Item that was right-clicked because I can't use Explorer.Selection since a right click does not select the item.

    Any ideas? (FYI I think I will raise this as a separate thread)

    FYI: As a work-around, I'm thinking I can still use the ItemContextMenuDisplay event to determine if the context menu is open when the Reply ribbon command is handled. The Ribbon command fires before the ContextMenuClose event so I would know that the Reply was from the context menu and to stay connected to the Item captured in the ItemContextMenuDisplay event.

    2. (Assuming the above is resolved) Using the Ribbon commands to capture all possible Reply events means that I now don't need to use wrappers at all. I only have to handle the appropriate control.Context in the Reply onAction to determine if I should connect Reply events to Explorer.Selection[1] or Inspector.CurrentItem.

    BUT there is still one more Reply mode that I have to handle - using the Ctrl-R shortcut. This does not raise a Ribbon command. Do you know if this can be captured (again I will raise this as a separate thread).

    Saturday, March 3, 2012 12:34 PM
  • Hamish, I apologize for the long delay in getting back to you on this. Did you still need assistance with this or do you have this up and running?

    Bill Jacob - Microsoft Customer Service & Support - Developer Messaging

    Thursday, April 5, 2012 5:24 PM
  • Hi Bill,

    I have it up and running thanks - it required a series of work-arounds and altered approaches but it all seems to work now.

    Cheers,

    Thursday, April 12, 2012 7:30 AM