none
SelectionPtr is NULL when right-click on message category and after back on the same message RRS feed

  • Question

  • I am very much positive the following is Microsoft Outlook issue (bug) which easy to reproduce. Outlook 2013 used as testing environment.

    In an add-on add hook-up to context menu as an example ...

    <customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui" onLoad="explorerRibbonLoaded">
      <contextMenus>    
        <contextMenu idMso="ContextMenuMailItem">
            <button id="EwTabContextEncryptItem" getVisible="GetVisible" getLabel="GetLabel" getImage="GetImage" onAction="OnButton"/>
        </contextMenu>
        <contextMenu idMso="ContextMenuMultipleItems">
            <button id="EwTabContextEncryptItems" getVisible="GetVisible" getLabel="GetLabel" getImage="GetImage" onAction="OnButton"/>
        </contextMenu>
      </contextMenus>
    </customUI>

    Implement "GetVisible" method for example as following ...

    STDMETHODIMP AddOn::GetVisible ( IDispatch* control, VARIANT_BOOL *pvarfVisible )
    {
    	Office::IRibbonControlPtr spControl = control;
    	wstring controlId = (wchar_t*)spControl->Id;
    	// in my case I am interesting only in mail messages
    	IMessagePtr spMessage = GetMailItemByContext( control );
    	if ( spMessage == NULL )
    		return S_OK;
    
    	// check Id from ribbon XML
    	if(!wcscmp( controlId.c_str(), RIBBON_EWTAB_CONTEXT_ENCRYPT_ITEM ) ||
    		!wcscmp( controlId.c_str(), RIBBON_EWTAB_CONTEXT_ENCRYPT_ITEMS ))
    	{
    		IDispatchPtr Context = spControl->GetContext();
    		SelectionPtr spSelection = Context;
    		// IMPORTANT! This is place where spSelection will be NULL 
    		// if follow instructions on how to reproduce the issue
    		// and add-on code which does something to selection never will run
    		// If do not check spSelection, "spSelection->Count" will produce crash. 
    		if ( spSelection && spSelection->Count > 0 )
    		{
    			// do something with selection
    			_MailItemPtr firstSelectedItem = spSelection->Item(1);
    			*pvarfVisible = VARIANT_TRUE;
    			return S_OK;
    		}
    	*pvarfVisible = VARIANT_FALSE;
    	}
    	return S_OK;
    }

    And now how to reproduce the Outlook issue ...

    Pre-request: User needs to have in the "messages list view" categories and expand list view wide enough to make click on categories.

    1: When user right-click on the message, it will be selected and add-on will get notified "GetVisible"; "Selection" object will hold currently selected message. User will see context menu for the message.  

    2: After user right-click on categories section of the message. Add-on is not notified (correct behavior) and user will see "categories" context menu for the selected message.

    3: Next user right-click on the same (selected) message again. Add-on get notified "GetVisible". This time "Selection" object will be NULL. User will see context menu for the message, but add-on code didn't run as there is no selection. Add-on would crash at this point if there is no check for NULL on "Selection" object.

    If user click somewhere else after right-click on category (#2) and right-click on message again "Selection" object will not be NULL and everything work as expected.

    If it possible I would like to hear any answers from Microsoft moderators on the issue.

    Thank you.


    Slava Ivanov

    Tuesday, February 17, 2015 4:08 PM

Answers

  • Thank you for the additional information. I did the same steps initially.

    >  Second right-click on the same message will not has "Selection" object.

    Yes, you need to cast the object to the Explorer or Selection types. Of course, it is strange to see different type of objects passed, but nobody guarantees that a Selection object should be passed all the time. Just add an additional line of code for checking the object type.

    I have just noticed the following statement in your reply above:

    > I am puzzled why would I need to invalidate control  on "GetVisible"? No I do that on toggleButton or onButton to "refresh" ribbon view, but never on any handlers as "GetVisible", "GetImage", etc. 

    There is no need to call the Invalidate method inside callbacks. You use it in the right way. Seems like I misunderstood your post.
    Wednesday, February 18, 2015 3:34 PM

All replies

  • Sounds like an Outlook bug. Nobody will fix it based on a forum post - you need to open a support case: you get 3 free cases a year if you are an MSDN subscriber. The fee will be waived if this turns out to be an Outlook bug.

    Is Application.ActiveExplorer.Selection also null?


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

    Tuesday, February 17, 2015 5:07 PM
  • Hello Slava,

    > After user right-click on categories section of the message. Add-on is not notified (correct behavior).

    You need to use the Invalidate or InvalidateControl method of the IRibbonUI interface to get the code invoked again for the same context menu. Ribbon caches previous values. Callbacks are invoked for new items only.

    > Next user right-click on the same (selected) message again. Add-on get notified "GetVisible". This time "Selection" object will be NULL.

    The Context property of the IRibbonControl interface returns an instance of the Explorer class in that case, not the Selection object.


    Tuesday, February 17, 2015 5:36 PM
  • Thank you very much, Dmitry and Eugene! I have tried all your suggestions (other than opening ticket under our MSDN) and the following are results ...

    Dmitry,

    By some reason, when I get selection from ActiveExplorer(), I always get Selection back ... never NULL. This would be very nice alternative the way I currently retrieve message selection.

    SelectionPtr spSelection1 = m_pApplication->ActiveExplorer()->Selection;

    Eugene,

    1. I am puzzled why would I need to invalidate control  on "GetVisible"? No I do that on toggleButton or onButton to "refresh" ribbon view, but never on any handlers as "GetVisible", "GetImage", etc. Any way I followed your suggestion and it didn't make any seance.  In either way I always get notified in "GetVisible" and the issue is happening all the time.

    2. I was completely unaware the second time right-click would return _ExplorerPtr, but Selection object and verified it. Yes it does! The first time Explorer would be NULL and Selection would be present. After right-click on the category and right-click on the message again Explorer will be available, but Selection will be NULL. This is absolutely new for me and it is not how it works under OL 2010 and lower. For OL2010 the Selection object will always hold selected message.

    Based on research above would would you suggest? ...

    1. Is this OL2013 issue or not? (should I submit ticket)

    2. What would be the best way to handle right-click to get selection ... as of

    - all the time call to "ActiveExplorer" and get selection from there

    - or call to  control->GetContext() and after try to get Selection; if it worked, use it; otherwise try to get Explorer and from this Explorer Selection and use it.

    Thank you.


    Slava Ivanov

    Tuesday, February 17, 2015 9:50 PM
  • Slava,

    I don't see anything strange in that. Try to take a screenshot of the place in Outlook where the context menu should be displayed. I will re-test the sample project and let you know my thoughts.

    You can use the "as" operator in C# to cast the Context property object to the real type. It returns null in case the object cannot be casted to the type.

    Tuesday, February 17, 2015 10:17 PM
  • Hi Slava,

    Thank you for posting in the MSDN Forum.
     
    I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.
     
    Sorry for any inconvenience and have a nice day!

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, February 18, 2015 2:54 AM
    Moderator
  • Fei,

    I don't see any issue there. I'd recommend testing the code carefully before involving anybody else.

    Slava,

    I'd suggest posting a screenshot because it doesn't clear where exactly you do the right click... The getVisible callback is called all the time in my tests. The Context property of the IRibbonControl returns a valid Outlook objects. Where is the issue???

    Wednesday, February 18, 2015 7:59 AM
  • Thank you for your help guys. I use C++ project, but everything you said when you cast Dispatch to an object is applicable here ... object will be NULL if object has different type. 

    I do understand I probably screwed up something to produce clear description on how to reproduce the issue and with my pleasure post screenshots. It is really weird sequence of user actions, but we found this from our customers, who used exactly this sequence. Here it is ...

    1. Right-click on a message in the messages list of explorer.

     

    2. Right-click on the same message Category.

    3. Right-click on the same message again (see screenshot #1)

    Observing results:

    First right-click on the message will has "Selection" object; Right-click on Category will not trigger handler in add-on code; Second right-click on the same message will not has "Selection" object.

    The following, as discovered, valid  for OL 2013 and when "Selection" object retrieved via Context of the Control.

    Thanks for help, very much appreciated.


    Slava Ivanov

    Wednesday, February 18, 2015 3:00 PM
  • Thank you for the additional information. I did the same steps initially.

    >  Second right-click on the same message will not has "Selection" object.

    Yes, you need to cast the object to the Explorer or Selection types. Of course, it is strange to see different type of objects passed, but nobody guarantees that a Selection object should be passed all the time. Just add an additional line of code for checking the object type.

    I have just noticed the following statement in your reply above:

    > I am puzzled why would I need to invalidate control  on "GetVisible"? No I do that on toggleButton or onButton to "refresh" ribbon view, but never on any handlers as "GetVisible", "GetImage", etc. 

    There is no need to call the Invalidate method inside callbacks. You use it in the right way. Seems like I misunderstood your post.
    Wednesday, February 18, 2015 3:34 PM
  • Eugene, thank you for your help, this is trivial work around and I will implement it as you suggested.

    All the best.


    Slava Ivanov

    Wednesday, February 18, 2015 3:46 PM