Building an Outlook add-in: Context Menu of Contact Card in Outlook 2010

Before going *any* further with VSTO code, I am taking some very good advice I gave myself a couple of years ago and installing some of the VSTO Power Tools (just the VSTO_PT.exe package) – specifically to obtain the VSTO Developer Cleaner and the VSTO Troubleshooter.  I recall both of these being very helpful, the last time I went down this path.

Note also: I am *not* going to pursue the Office Interop API Extensions.  I am aware they’re targeted specifically at easing C# development of VSTO apps in Word, Excel and Outlook.  However, after reading PhillipHoff’s blog that “documented” them, the near-total lack of a deployment story is enough to encourage me to tough it out without ‘em:

“You are correct in that the User Guide does not explicitly state that you cannot use VSTO_PTExtLibs.exe to redistribute the extension assemblies, but as you found, the installer has a dependency check which prevents it from being used for that purpose.

“You have two basic options for distributing the extension assembly: either a custom installer that places it in the GAC or another common location, or side-by-side the referencing assembly.”

Heh, yeah right.  A year or two ago I feel down the rabbit hole of developing a custom setup package for a Word VSTO app add-in.  That sucked me dry for months, and I never got any satisfaction out of it (tho it’ll probably save me a couple of months this time around).  *Voluntarily* adding to my pain by trying to install a helper assembly of dubious provenance and poor support?  Not bloody likely my friends.

 

Creating a WPF Control for use within Outlook 2010

Diving back into this video tutorial.  Already stuck on one of the first steps – adding the WPF “User Control” to the ElementHost winforms container.  Even though I’m able to successfully build the project, there’s no WPF user control to add to the ElementHost (at least that’s what the ElementHost “Select Hosted Content” taskpane is indicating.  Google it is… searching on elementhost “select hosted content” none:

…actually, I just remembered how many articles I’ve been skimming are focused so strongly on .NET Framework 4, so first I decided to re-target the VSTO project to .NET 4.  For some reason that seems to have wiped out the piece of code that contained the ElementHost-including form, so perhaps that’ll clear up the problem I’ve been having.

I ended up Building the project and failing, needing to add a Reference to System.Xaml (from the .NET 4 namepsace) to one of the .CS files.  Once I did that, magically I was able to add either of the XAML user controls I’d tried to create as children of the ElementHost object.  Amazing.

I’m re-trying this approach with an Office Ribbon (XML) item as is outlined in Customizing the Context Menu of a Contact Card in Outlook 2010.  I change the button element’s id, label, and onAction XML parameters, then run this article’s VB-only code through a VB-to-C# converter to import into my code.  Each time I have to fill in a few blanks along the way – figuring out which method to add to my code, to which CS library, and matching some undeclared variable names and using statements up with orphaned code in the sample.  What moron would expect a “Visual How To” from Microsoft to ever run without a ton of band-aid work to actually fill in boring-but-essential components?

Once I figured out how this sample code would instantiate the Ribbon (XML) item, I only have two more tasks before I start binding the XAML to its data source:

  1. instantiating the XAML-encapsulated-in-WinForms control, and
  2. creating the Callback Methods that are hinted at (but not spelled out) in the Ribbon (XML) //TODO section (automatically generated by Visual Studio when I created the Ribbon (XML) object.

Yeah, that should be easy.  Callbacks – is that like in the theatre?  Hell, for all *I* know, (2) is where I *implement* (1).

Aha!  Apparently I’m not far off from the truth – the Walkthrough: Creating a Custom Tab by Using Ribbon XML says:

You must add onAction callback methods for the Insert Text and Insert Table buttons to perform actions when the user clicks them.

Right right right – so the meaning of “callbacks” is coming slowly back to me – at least in the context of button pushing. 🙂

 

Problem: UserControl doesn’t Show()

I spent some time looking for a suitable approach to rendering the WPF Element Host-ing user control, and tried a couple of approaches, but none work so far.  The approach I’ve landed on instantiates a new instance of the Class that hosts the ElementHost (here called “DataDetails”), then calls the .Show() method for the object instance, like so:

DataDetails dataDisplay = new DataDetails();
dataDisplay.Show();

However nothing appears visible when I click the new context menu item in Outlook 2010.  Here’s what I’ve tried, none of which tells me why this won’t display:

  • follow the .Show() call with calling the BringToFront() method, in case somehow the user control was being hidden behind Outlook
  • added a straight System.Windows.Forms class to the project (called it my Debug window), then instantiate it as for the DataDetails class instance and call the ShowDialog() or Show() method [which works]
  • did a line-by-line debug of this area of my code [which proves that every line of code is being called – nothing skipped – but the ElementHost is still not showing up]

Re-examining the Debug vs. DataDetails objects, I’m pretty convinced that using the Form class is easy, but there’s some step I’m still missing when using the UserControl class.  This is borne out when I merely substitute “Form” in place of the original “UserControl” for the partial inheritance, like so:

public partial class DataDetails : Form

{

    public DataDetails() {  InitializeComponent(); }

}

Further Research References

Aside: the specific Context Menu I’m manipulating here is sometimes called the Persona Context Menu (at least by the article Extending the User Interface in Outlook 2010).  I have a feeling that will be a very useful phrases in my current research.

Other articles I’ll probably need to almost immediately:

Here are some other articles I expect I’ll need in the future:

Finally, here are some possible sources of working code that I’ve found in my travels:

Advertisements

Building an Outlook Add-in: customizing the Contact Card, other options?

[I’m working on an app for work – enable me to pull job title, team name, etc. from a proprietary internal database, since our Exchange Address Book doesn’t contain that info.  Just to set the context for what the h*** I’m up to.]

Did a broad search for “Outlook 2010 VSTO” to find some beginners’ guide to writing something that will run in Outlook 2010.  Lots of possible stuff to read, but this 20-minute video seemed like my best bet:

How Do I: Create a WPF Control for Use Within Outlook 2010

Yes the question should be asked: are you better off writing an Outlook 2010 add-in using WPF or a Windows Forms?  I haven’t yet found a definitive answer, and they may both be supported to some degree, but the majority of articles I stumbled across were using WPF not Windows Forms.  That *may* just be a tyrannical bias coming from Microsoft, where XAML is all the rage and you’re ‘not allowed’ to talk about legacy development there anymore.  Regardless, if I see WPF and Outlook 2010 mentioned more than a half-dozen times, that *has* to be supported pretty well, so I’ll go with that for now.

Contact Card

Next I need to know what kind of Outlook “object” I’m trying to attach to.  I am aiming for that new intermediate Contact panel that shows up when you double-click the email address of an email in your Inbox (this example borrowed from Microsoft Support):

Contact Card example

  1. It already has a tabbed interface, so adding another tab makes intuitive sense as a user.
  2. It’s the first interface you get to detailed info on a user, so it’s the fewest clicks to get to an extended UI I could add.
  3. It’s new in Outlook 2010, which (I hope) means that the Outlook Interop object model has implemented first-class .NET support for interacting with that object.  [As opposed to some of the legacy objects in Outlook for which there is pretty crappy support in the .NET Interop model.]

Searches for “Outlook 2010 new features” take me to pages like this, which refer to this new interface as “a new easy-to-access contact card”.  Digging into the official Outlook blog there’s a detailed article “Using the contact card to learn who someone is”, so I’m definitely on the right track.  Now if only this was the same nomenclature used in the Outlook object model (developer side of the world) – it’s rare that the underlying code and the marketing names ever get aligned, so I’m not surprised much anymore if I don’t get that fantasy fulfilled.  [Heh, and just to show how easy it could’ve been, I realize now that the Contact Card is available as a context menu item when you right-click the email address.]

So my next search – Outlook 2010 “contact card” “object model” – turned up an article called “Customizing the Context Menu of a Contact Card in Outlook 2010”.  Among other things, this article states that “The IMsoContactCard object is defined in the primary interop assembly, Office.dll, of the Microsoft Office object library, not in Outlook 2010.”  So this is apparently an Office-wide object, available to other Office apps – not just Outlook (though it’s entirely possible Outlook is the only app that bothered).

Which also happens to lead to a Code Gallery sample called “Outlook 2010: Visual How Tos: Code Samples” that includes the sample code.  Unfortuately the sample is adding a new entry to the context menu, not to the Contact Card itself (which is a mite confusing, as the object model doesn’t make a really clear distinction between the two).  HOwever, this gives me a great lead on what area of the object model to focus my attention on.  And worse come to worst, I can always start with a really crude hack of adding a context menu selection that just pulls up the internal directory data for the selected user (or as I’m seeing from the code sample, the “Recipient” – gotta get your nomenclature aligned when you dive into an Office object model exploration).

Next let’s see if anyone out there has been monkeying with this object or this part of the object model – searches on Stack Overflow turn up nothing, but MSDN Social Forums hits some info on:

And a search of MSDN Library for IMsoContactCard led to one non-reference article: Extending the User Interface in Outlook 2010.  According to this article, adding a new item to the context menu when you right-click an email sender or recipient is done using the ContextMenuContactCardRecipient context menu.

Given that these articles all seem to say that it’s impossible to extend the contact card itself, I find myself with two alternatives:

  1. Add a right-click menu option that pulls the internal directory info for the selected recipient.
  2. Add another tab to the ‘legacy’ Outlook Properties window (which was the default in Outlook 2007 & 2003 when you double-click on a user).

Context Menu vs. Properties window

Comparing Option (1) and (2), I come to these benefits & drawbacks:

  1. The programming for the Contact Card context menu was just added in 2010, which probably makes it behave more consistently and robustly than the COM-based crap that comes with legacy Outlook features.
  2. Adding a tab to the Properties window (form) would assist me more easily if I wanted to “crawl up the address book” (i.e. look for the same information on the managers of the recipient I’m exploring).  I find I *can* get to a context menu for the recipient’s manager, but it’s hellishly buried and I’d probably be one of three people who’d find it (or who’d bother taking this path).
  3. From my recollection, Office (and Outlook in particular) can be really picky about exactly how and when to dispose of objects – generally resulting (from <100% perfect code) in deadlocks, memory leaks or difficulties in shutting down the hosting app.  I would imagine the Interop Assemblies have a harder time communicating reliably with the legacy COM object model (e.g. Properties window) than with objects only recently introduced (e.g. Fluent UI).
  4. While the Office Interop Assemblies have been incredibly forgiving about providing backwards-compatibility to all the COM objects that have been accumulated over the decades, I have to believe that Fluent UI customizations have a better future in coming versions of Office than COM-based customizations.  This should be especially true of Outlook, since that team took a “wait and see” approach to the Fluent UI in the Outlook 2007 generation.  If they’re still on board, they’ve benefited from the delay *and* it is likely they’re more committed than if they’d gotten burned by jumping in early.
  5. If I’m reading this right, Office Communicator (probably 2007 R2 and later) implements support for the IMsoContactCard – so a Fluent UI approach might actually give us coverage in Outlook *and* Communicator.  I don’t know how useful that really would be, but it *sounds* cool.

Thinking as an end user, I’d find another tab on the Outlook Properties window more intuitive, but I’d also be extremely unforgiving if my Outlook user experience slowed down or destabilized.  I don’t like the Context Menu approach that I seem to be left with in customizing the Fluent UI, but I can be optimistic that a more integrated approach will become apparent as my research continues – and in the meantime I’ll have a Fluent UI-compatible set of code to build on.

Details: Fluent UI

All these articles I’m finding talk about these Contact Card customizations in terms of customizing the “Fluent UI”.  I’m not sure, but I had believed that this Fluent UI was primarily introduced as a wrapping layer of menu/ribbon ‘cleanup’ of the Office UI that was long overdue by Office 2007.  These references make it sound as if the Fluent UI is where all new UI improvements are “homed” in Outlook 2010.

As I dig a little further, there are some pretty clear indications this is true:

Customize the Office UI

In Office 2010, the Office Fluent UI is fully customizable. This includes the ribbon, the Quick Access Toolbar, and the built-in context menus. By using the flexible XML-based markup and callbacks, you can create context menus by updating Open XML Format files or by using add-ins that are created in Microsoft Visual Studio.

Customizing Context Menus in Office 2010

In Office 2010, you can customize built-in context menus just as you can the other components of the Ribbon UI. This XML-based context menu extensibility model is based on the familiar Ribbon extensibility model. This means that you can use the same XML markup and callbacks that you currently use to customize the Ribbon UI.

Encouraging, but not specifically helpful other than a lot of hand-waving and empty promises.  Having clear documentation on what the object model does is the critical piece, and all I’ve got here so far is a Context menu (which is hardly an intuitive UI approach).  However, if that’s what I’ve got then it’ll have to do.  Off to implement code based on Customizing the Context Menu of a Contact Card in Outlook 2010 and see how well that treats me.