Outlook Ribbon woes on performing “Send As E-Mail” via other Office 2010 Apps

 

When we introduced ribbons  in various Office applications with Office 2007 (and expanded it further in 2010), we also brought to you a quick and easy GUI tool, called the Ribbon Designer, to help you design your custom ribbons via Visual Studio, in a manner in which WYSIWYG.

Unfortunately, come Office 2010, as far as the Ribbon Designer is concerned,in very specific scenario, WYS is not always WYG.

I can’t emphasize that the scenario is indeed very specific, and if you find your users encountering it, this blog is just right for you!

Let’s assume your users tend to do quite a bit of e-mailing, hence Outlook is almost always running in the background. Let’s also assume that they work a lot with Excel or Word documents, and tend to email them out directly from within Excel/Word by navigating to “File –> Save & Send –> Send As Attachment”. Finally, let’s assume that you’ve customized the ribbon of the Outlook Compose inspector (i.e. Microsoft.Outlook.Mail.Compose) and have used the Ribbon Designer to accomplish this purpose.

Given that all of the above assumptions are true, i.e. while Outlook is running in the background, a user creates a new Excel/Word document, then tries to email it through File->Save&Send->SendAsAttachment and you’ve customized the compose editor ribbon, your user will tragically find that on trying to Save the document after e-mailing it out, the Save/SaveAs dialog box is lost somewhere behind the Word/Excel document window, and quite inaccessible (until you navigate to Start –> Run –> Outlook /reportleakedrenitems) which somehow exorcises the ghost that is suppressing that Save/SaveAs dialog window.

The short version of the story is that this is due to a known issue with ribbons designed using the Ribbon Designer. (You won’t encounter the issue if your ribbon isn’t customized, in which case you can close this webpage and move on to something more interesting).

The long version of the story is that this is our unusual way of introducing you to the beauty of…

RibbonXML!

Or in more sober terms, the easiest way for you to avoiding this issue is exporting your custom ribbon to use RibbonXML.

One could write pages about how RibbonXML gives you more control over the appearance, functionality and flexibility you can exercise with your custom ribbon. In fact, we’ve written a few pages on it over here: https://msdn.microsoft.com/en-us/library/bb386097(v=vs.90).aspx

Additionally, we’ve also done our best to to make this transition from Ribbon Designer to RibbonXML by publishing this article to get you kick-started: https://msdn.microsoft.com/en-us/library/bb386297(v=vs.90).aspx

The bigger challenge is understanding how RibbonXML works. Naturally, this article would perform the job to some extent for you:https://msdn.microsoft.com/en-us/library/aa942866(v=vs.90).aspx

To compare the 2 in a nutshell though, when you dump the Ribbon Designer in favour of the super-fabulous RibbonXML, you’ll find that every entity in the RibbonXML (buttons, toggle buttons, groups, tabs, check-boxes, drop-down boxes etc.) comes with its own set of attributes. Each of these attributes allows you to determine its appearance and behavior… whether it’s visible/invisible, enabled/disabled, or what happens when you perform an associated action.

For instance, you have the option of pre-defining whether an element is visible at all times, i.e.

<tab id=”New Tab” visible=true />

or whether you want an element to be either visible or invisible depending on a certain condition which may change dynamically, i.e.

<tab id=”New Tab” getVisible=”getElementVisibility” />

and subsequently define the corresponding callback as such:

bool getElementVisibility(IRibbonControl control)
{

            if(control.Id = “New Tab”)
return newTabVisible;

}

There’s an excellent compilation of callbacks associated with each type of element, along with descriptions and their signatures in Part 3 of a 30part series on how to develop ribbons, accessible here: https://msdn.microsoft.com/en-us/library/aa722523%28v=office.12%29.aspx

For example, the onAction callback is usually the most useful in executing logic that is to be triggered when a certain control is modified. Similarly, the getSelectedItemId and getSelectedItemIndex callbacks come in handy for determining the selected value in a drop-down box.

The trickier part can be to dynamically modify the contents of a Combo Box/DropDown list, but the getItemCount, getItemLabel and getItemId callbacks can come in handy here, although one must remember to call the Invalidate() method on the ribbon (or the InvalidateControl(ctrl.Id) method on a specific control) for those changes to reflect.

Another excellent resource to read if you’re creating a Ribbon that should change depending on user action/input, or be dependent on any other factors can be found here: https://msdn.microsoft.com/en-us/library/dd548010%28v=office.12%29.aspx
Although written around programming for Access, it’s a great way to learn concepts.

Delay not further in ridding yourself of Visual Designer limitations and discovering the versatility and sheer power of RibbonXML programming! Dive write in and enjoy the power of customization!

Until next time!

Comments

• Anonymous
  June 18, 2013
  I have also seen this behavior with forms I have created in Excel and we DO NOT use Outlook (yet) at General Motors. Often, if a form is displayed while substantial processing is happening, when control passes back to the form it disappears from view.  My most common "fix" is to click on Lotus Notes to give it focus and then dismiss it to the tray.  When Excel reappears, the form is again viewable.

• Anonymous
  March 13, 2014
  Is there any further information about the underlying problem here? What exactly is it that the Ribbon Designer does that triggers this? I ask because we've created an Outlook add-in that also seems to trigger this problem, but uses RibbonXML directly - we've never used VSTO at all. Any information would be gratefully received :-)