R
rkozlin
When coding for Outlook in C#.Net you may want to capture the current
MailItem's send event. The issue starts with the fact that the Send method
hides the Send event. For this reason, Microsoft created a 'MailItemClass'
interface that includes events as 'ItemEvents_...' etc. Yeah, I know, this
is retarded, but unfortunately we have to deal with it...
Dealing with it #1:
Okay so many of you may know about this around because you are familiar with
casting an Inspector object into an InspectorClass in order to get access to
the Inspector's hidden events. So we then take this same approach to the
MailItem/MailItemClass situation. But... to your horror you get some totally
whacked casting exception?!?!? Hmm... yep... that's a BUG! (If anyone from
MS tries to say otherwise, all we need to do is ask them to explain how to
instantiate a MailItemClass object.)
Dealing with it #2:
A kludge that will work involves using the Application object because it is
the only other place where an event is fired in regard to an email being
sent. So we capture the Application.ItemSend event. The problem here is
that the function you assign to the event will fire for every mail being sent
- not just the current item you are working with.
To get around this we need to look at the UserProperties collection on the
MailItem (current item). Go back to where you are first getting your hands
on the current item - for me this was in the
Application.Inspectors.NewInspector event. There you need to do something as
follows:
OLOOK.UserProperty oProp = _oMI.UserProperties.Add("InspectorWrapper",
OLOOK.OlUserPropertyType.olText, System.Reflection.Missing.Value,
System.Reflection.Missing.Value);
oProp.Value = "YES";
System.Runtime.InteropServices.Marshal.ReleaseComObject(oProp);
oProp = null;
The property does not have to be a string, the second parameter of the Add
method asks for the type. All you really need to do is flag the item as the
current item you are working on. That way when you run your method for
Application.ItemSend you can then check for the existance of your custom
UserProperty. If it's not there then just skip running your method.
Onbviously a left out a lot of detail with the assumption that those reading
will be at least somewhat adept at coding for Outlook already. If anyone
needs more info let me know.
MailItem's send event. The issue starts with the fact that the Send method
hides the Send event. For this reason, Microsoft created a 'MailItemClass'
interface that includes events as 'ItemEvents_...' etc. Yeah, I know, this
is retarded, but unfortunately we have to deal with it...
Dealing with it #1:
Okay so many of you may know about this around because you are familiar with
casting an Inspector object into an InspectorClass in order to get access to
the Inspector's hidden events. So we then take this same approach to the
MailItem/MailItemClass situation. But... to your horror you get some totally
whacked casting exception?!?!? Hmm... yep... that's a BUG! (If anyone from
MS tries to say otherwise, all we need to do is ask them to explain how to
instantiate a MailItemClass object.)
Dealing with it #2:
A kludge that will work involves using the Application object because it is
the only other place where an event is fired in regard to an email being
sent. So we capture the Application.ItemSend event. The problem here is
that the function you assign to the event will fire for every mail being sent
- not just the current item you are working with.
To get around this we need to look at the UserProperties collection on the
MailItem (current item). Go back to where you are first getting your hands
on the current item - for me this was in the
Application.Inspectors.NewInspector event. There you need to do something as
follows:
OLOOK.UserProperty oProp = _oMI.UserProperties.Add("InspectorWrapper",
OLOOK.OlUserPropertyType.olText, System.Reflection.Missing.Value,
System.Reflection.Missing.Value);
oProp.Value = "YES";
System.Runtime.InteropServices.Marshal.ReleaseComObject(oProp);
oProp = null;
The property does not have to be a string, the second parameter of the Add
method asks for the type. All you really need to do is flag the item as the
current item you are working on. That way when you run your method for
Application.ItemSend you can then check for the existance of your custom
UserProperty. If it's not there then just skip running your method.
Onbviously a left out a lot of detail with the assumption that those reading
will be at least somewhat adept at coding for Outlook already. If anyone
needs more info let me know.