Do this by employing a wrapper class. Outlook’s Application object has an Inspectors collection that raises a NewInspector event every time the user opens an item. You can use that event to create a wrapper object that contains the Inspector and can react to events such as button clicks on that Inspector:
Friend WithEvents gcolInspectors As Outlook.Inspectors
Friend gcolInspectorWrappers As New InspectorWrappers
Private Sub ThisApplication_Startup(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles Me.Startup
gcolInspectors = Globals.ThisApplication.Inspectors
Private Sub gcolInspectors_NewInspector(ByVal Inspector As Outlook.Inspector) _
If TypeOf Inspector.CurrentItem Is Outlook.MailItem Then
The wrapper class just has to contain private variables, declared as WithEvents, to hold the Inspector, the MailItem and any toolbar buttons you want to add to it, and you can then create handlers for any of the events of those objects. You can also add your wrapper object to a collection of wrapper objects, so you can keep track of it and destroy it once the user closes the Inspector. It isn’t good practice to continue adding to your collection of InspectorWrappers without removing any, as you’d gradually use up all the memory and probably crash Outlook, if not the whole of Windows.
You need an InspectorWrappers collection class that has Add and Remove methods. Add would take an Inspector as its argument, and then create the requisite InspectorWrapper object containing the Inspector and add this wrapper to the collection. The Remove method should take an index or key and remove the wrapper it refers to from the collection.
Any further intelligence that’s required you can put into the InspectorWrapper class itself. Within its New event, you can accept the Inspector given as a parameter, assign a unique key to this wrapper and add your button to its toolbar, the unique key generated from a shared integer variable. Since it’s shared, any instance of the InspectorWrapper class can get the next ID number and increment it. Also, you need only add your button if this email hasn’t been sent yet, so test for that condition.
Private Shared gintNextInspectorID As Integer
Friend Sub New(ByVal value As Outlook.Inspector)
mobjInspector = value
mstrKey = CStr(gintNextInspectorID)
gintNextInspectorID += 1
mobjMailItem = CType(mobjInspector.CurrentItem, Outlook.MailItem)
If Not mobjMailItem.Sent Then
In the Inspector.Close event, you can remove the corresponding wrapper object from the collection using its unique key.
Private Sub mobjInspector_Close() Handles mobjInspector.Close
As for the user interface, my initial thought was to remove the Send button from the toolbar on the Compose Email Inspector, and add instead a split button that had options “Send as Brand A”, “Send as Brand B” and so on. The user would click the down arrow on this button to choose which brand to send it from. For new messages, you’d have this button default to “Send as Brand A”, but for replies you’d want it to default to whichever brand was addressed by the original message. Unfortunately, it turns out that the Office 2003 object model is a little restrictive as to what kind of buttons you can create: split buttons do exist in the object model, but you can’t create new ones. Eventually, we settled on renaming the “Send” button to “Send As…” and then putting a drop-down list next to it, which listed the various brands. Sending via a different brand now required two clicks, but at least we could do a proper job on replies by ensuring they were sent from the correct brand without needing any user intervention.