Ty Anderson

Outlook Object Model: 4 things developers might not know

I might have mentioned previously that I coach baseball. Have I mentioned that I coach 10-and under baseball? It’s a zoo! Sometimes (and by sometimes, I mean every single practice) it is difficult to get my ball players to focus on the fundamentals… the basics of the game.

When confronted by this situation, I resort to a trick. I cover an advanced skill. Barring that, I cover lesser known topics. In either case, these topics are something that, if mastered, will make you superior to your competition. It always works. Who doesn’t want to know some insider tricks? Something to make you feel superior to your competition? The answer is “no one”!

Today, I will cover 4 topics of Outlook development tasks that are not commonly known or mainstream. You can argue about how well known each task is but you will lose. These tasks are not commonly known because you don’t always need them. They are beyond the basics. But, if you master them, you can look upon other Outlook developer with a snooty little smirk.

  1. Control which Outlook account sends the email
  2. Hide information to use later
  3. Extend the Outlook Social Connector
  4. You are not limited to Outlook Object model to work with Outlook data (MAPI)

1. Control which Outlook account sends the email


Provides the ability to obtain the account that is selected in the Microsoft Office Backstage view for the parent.

Why use?

You have users that have multiple accounts setup within Outlook.

–And–

These users want to ensure they send messages from a certain address when sending to certain people.

When should i do it?

I like to use the Item_Send event. In this event, you can grab the email that Outlook is sending and change it. It’s the perfect place to check the TO field to determine if the email targets a specified domain or user. If it does, you can quickly change the account the user sends the email from… if needed.

How do I do it?

#Region "1. CONTROL WHICH ACCOUNT SENDS THE EMAIL"
Private Sub adxOutlookEvents_ItemSend(sender As Object, e As ADXOlItemSendEventArgs) _
	Handles adxOutlookEvents.ItemSend
 
	Dim mail As Outlook.MailItem
	mail = TryCast(e.Item, Outlook.MailItem)
 
	If mail.SenderEmailAddress <> "ty@add-in-express.com" Then
		e.Cancel = True
 
	End If
 
	If mail.To.Contains("microsoft.com") Then
		Dim account As Outlook.Account = _
			GetAccountForEmailAddress(OutlookApp.Application, "ty@microsoft.com")
		' Use this account to send the e-mail. 
		mail.SendUsingAccount = account
		mail.Send()
	End If
 
End Sub
 
Shared Function GetAccountForEmailAddress(ByVal application As Outlook.Application, _
	ByVal smtpAddress As String) As Outlook.Account
 
	' Straight off MSDN
	' Loop over the Accounts collection of the current Outlook session. 
	Dim accounts As Outlook.Accounts = application.Session.Accounts
	Dim account As Outlook.Account
	For Each account In accounts
		' When the e-mail address matches, return the account. 
		If account.SmtpAddress = smtpAddress Then
			Return account
		End If
	Next
	Throw New System.Exception( _
		String.Format("No Account with SmtpAddress: {0} exists!", smtpAddress))
End Function
 
#End Region

Where can I go to learn more

(besides add-in-express of course :)

2. Hide information to use later


Outlook supports several types of items. Many of you know already… like Mail, Appointments, Contacts, and Tasks. Other might not be as obvious (e.g. Post Items). Others are meant to remain hidden and are to be used by the true experts… Outlook developers! The Outlook StorageItem is one such item.

The StorageItem is meant for storing private data within an Outlook solution. It allows you to store text-based data for your solution and keep it from the prying eyes of your users.

Why use it?

  1. You want to store settings or other information needed by your solution.
  2. You want this information to roam with the user.
  3. You want the information available online and offline.

When should I do it?

This is best used for simple data needs or when you have a bit of information you want to make available on any machine the user uses your add-in.

How do I do it?

First you need to edit the AddinModule‘s New method to include this bit of code:

Dim item As Outlook.StorageItem = StoreItemData()
MsgBox("Properties Set" & vbCrLf & _
	"First Run Date: " & item.UserProperties("FirstRunDate").Value & vbCrLf & _
	"Number Of Times Run:" & item.UserProperties("NumberOfTimesRun").Value)

Next add this function that will add a StorageItem and/or update it, depending on the situation:

Private Function StoreItemData() As Outlook.StorageItem
 
	Dim fldStorageItem As Outlook.Folder
	fldStorageItem = Me.OutlookApp.Session.GetDefaultFolder( _
		Outlook.OlDefaultFolders.olFolderInbox)
 
	'Create and store the item.
	Dim si As Outlook.StorageItem
	si = fldStorageItem.GetStorage("HDI.StorageItemVideo.Settings",   
	  Outlook.OlStorageIdentifierType.olIdentifyBySubject)
 
	'The way to know if the item is new is to check its size.
	If si.Size = 0 Then
		'No setting exists so create them.
		si.UserProperties.Add("FirstRunDate", Outlook.OlUserPropertyType.olDateTime)
		si.UserProperties.Add("NumberOfTimesRun", Outlook.OlUserPropertyType.olInteger)
 
		si.UserProperties("FirstRunDate").Value = Now()
		si.UserProperties("NumberOfTimesRun").Value = 1
 
	Else
		Dim iCount As Integer = si.UserProperties("NumberOfTimesRun").Value + 1
		si.UserProperties("NumberOfTimesRun").Value = iCount
	End If
	si.Save()
	Return si
End Function

Where can I go to learn more

3. Extend the Outlook Social Connector


Outlook is an old, lovely, grey mare. She was born in 1998 and is long-in-the-tooth. Social media and “life broadcasting” were unknown when the Microsofties conceived of her. In fact, even with Outlook 2010, social media was an afterthought. Outlook 2010 released without any social media features. But, soon after the release, the Outlook Social Connector (OSC) became available.

The idea behind Outlook Social Connector is to provide a framework that is easily extended to connect and interact social networks. This is a solid strategy given the fickleness we have with social media.

Why extend it?

By and large I don’t think you should. The reason is the largest and most popular social networks (like LinkedIn) will do this for you. If they don’t, Microsoft probably will. But… what if you have an internal, custom built social network of sort or the other? This would be a good scenario for you to extend the Outlook Social Connector.

When should I do it?

The decision to do it should be weighed carefully. Email is already distracting enough. People are addicted to it, check it way too often, and don’t focus on their work. So, I suggest pursuing this option only if doing so will increase the productivity of your users. I realize that last sentence can be judged on a sliding scale.

How do i do it?

  1. Download the provider templates.
  2. Develop a provider :: This step requires you implement four interfaces that handle the logic for working with the social provider, the social network, the user’s profile, and the other people in the social network.

Microsoft’s marketing material glosses over the extensibility model. Their glib statements hide the fact that this isn’t a main stream extensibility model. However, it exists and might be useful to you.

Where can I go to learn more

4. You are not limited to Outlook Object model to work with Outlook data (MAPI)


MAPI, (Messaging Application Programming Interface) is a messaging protocol. Any client can use it and Outlook is the most well-known client consumer of it. Regarding Outlook, MAPI gives you low-level access to data in the Outlook MAPI store. This is a fancy way of saying MAPI lets you bypass the business logic in Outlook’s object model.

Why use it?

  • Access Outlook data directly (without using the Outlook OM)
  • Integrate data from another data source (e.g. a database or LOB application)
  • Need multi-threading support
  • Want to build a sync provider
  • Want to access Outlook data via a Windows Service application
  • See the list above… ditto.
  • If you don’t require these, keep this in mind.

When should I do it?

How do I do it?

It isn’t easy. It requires knowledge of C++ and the ability to endure long periods of pain.

Where can I go to learn more

There you have it

Some of these are easy to implement and some of them require a bit more assembly and climbing of the learning curve. At the very least you now know about them and that, I’ve been told, is half the battle.

You may also be interested in:

2 Comments

  • Oliver says:

    Rgd. your sample code for controlling the sending account:

    Did you merely forget to remove the mail.Send() line when you copied the MSDN example or would you actually recommend calling that from within the Item.Send event handler? If so, why?
    Wouldn’t this mess with the event chain?

    Cheers,

    Oliver

  • Ty Anderson says:

    Nice catch Oliver!
    Given the event is ItemSend, you don’t need the call to Mail.Send();

    Ty

Post a comment

Have any questions? Ask us right now!