Questions from "novice" regarding developing a program that needs access to Outlook contact data

[Ted Byers]

While I have been programming for two dozen years, in fortran, C++ BASIC,
and a few other languages, I have yet to develop a program that needed to
interact with an MS Office application. Now I need to do so, so a
quickstart boost would be useful. I can use either VB or VC++ for this.

Here is what I need to do.

1) The first time my program starts, it needs to validate its own contact
information with all of the contact information in Outlook at the time.

2) Assuming my program is subsequently started whenever the OS is started,
it needs to be notified whenever contact information is edited or added. I
must therefore ask if Outlook published events that my program can respond
to. On the outside chance that my program isn't running at the time contact
information is changed within Outlook, is it possible to configure outlook
to start my program if it isn't running at the time the change is made. If
my program needs to edit contact information in Outlook, is it possible to
distinguish between edits made through the user interface and those made by
my program (I assume that add or change events would be generated in both
cases, so I'd need a way to distinguish the two cases).

Here are some other questions: "Is it possible to configure Outlook on
workstations on a LAN to share a contact database even if the LAN is not
running MS Exchange?" "Is it possible to have a program running on one
workstation access the Outlook contact data on another workstation (provided
appropriate persmissions can be set by the network administrator)?" For
each of these questions "If so, how?"

Sample code, either in your response or which can be found at some URL,
would be greatly appreciated, especially if it shows how to access each of
the elements of the contact information.

Thanks for any help you can provide.

Cheers,

Ted

 

[Ken Slovak - [MVP - Outlook]]

The Items collection of a MAPIFolder can be declared and instantiated
using WithEvents, which would enable you to handle the ItemChange and
ItemAdd events. ItemRemove is rather useless.

I'd set up the code as an Outlook COM addin so it was started when
Outlook started.

See the ItemsCB COM addin sample on the Resources page at
www.microeye.com for a VB6 example of an Outlook COM addin that shows
best practices and how to handle WithEvents declarations. Also see the
dev information at http://www.slipstick.com/dev/comaddins.htm and
http://www.slipstick.com/dev/vb.htm

 

[Ted Byers]

Thanks Ken,

That is a useful start.

Can I ask a couple more questions?

1) Do I have to do anything special to ensure that Outlook's default event
handling occurs (since I don't want to change that), I just want to know a)
that the event occured, and b) what the original and new data are?

2) Does it matter whether the COM addin is inline or out of line? I am
looking at a project which in fact involves several applications, and I need
to to be able to react to events they generate as well as to those generated
by Outlook.

3) If I am developing this using the Enterprise edition of Visual Studio 6,
on W2K and with Office 2000, will my code run as well on more recent
versions of Windows and Office? (I guess this is another way of asking if MS
has backward compatibility issues that will bite me).

4) How much flexibility is there in the event processing protocols? For
example, can I make my own event class, derived from that used by Windows,
into which I can put information about the process that actually generated
the event (so when my program receives such an event, it can tell whether or
not it has already been processed by my program)? Or, do I even need to do
this (i.e. do events carry information I can access WRT the process that
generated the event)?

I notice you wrote the book on Outlook programming, so let me ask if you
have had to deal with situations in which you had to syncronize contact data
on several workstations in a peer to peer LAN, and with MS Exchange
installed? If so, how did you deal with it? Especially, what did you do if
two users, on two machines in the network, made inconsistent changes to the
same contact data?

Thanks again.

Cheers,

Ted

 

[Ken Slovak - [MVP - Outlook]]

That's more than a couple of questions...

If declared using WithEvents and instantiated correctly you can handle
any Outlook event. An ItemChange event won't tell you what the old
data was however, it just passes you the Item that was changed. You
would have to maintain some way of recording old data to compare. You
can also handle the events for any item in an Items collection, such
as Item.PropertyChange and Item.UserProperty change to get the changes
as they occur. For properties you are interested in you can store the
old data in a UserProperty or even in a database file. It all comes
down to seeing which events are available and deciding how you want to
handle them. The algorithm might take more time to design than the
coding.

Outlook COM addins run in-process with Outlook. So they can only run
if Outlook is running and they run as part of the Outlook process.
That said, if running you can expose public methods or properties and
even class events in your addin to the outside world and call them for
processing within your COM addin. One example of that is telling a COM
addin that some registry setting has changed so the addin knows to
change its settings. An ActiveX control used as a property page for
the addin can do that. Another example would be what I do in my
Reminder Manager addin, where I use a form in the addin that handles a
call-back from Windows when the system tray icon for Reminder Manager
is accessed to open the correct form from within the addin. Lots of
things you can do.

Always develop using the earliest version of Outlook you want to
support. If you want to add support for a later version's added
methods or properties check for the Outlook runtime version and use
late binding on an Outlook object so you can access the method or
property and not throw off compiler errors when you compile the addin.
I do that for different methods of checking for online/offline status
depending on Outlook version and presence or absence of Exchange
server. My main dev machine runs Windows 2000 but code developed on it
runs on WinXP as well as Win98. Most important thing is to distribute
any OCX's or other controls you are referencing in your project. You
don't need to distribute any VB runtimes unless you intend to support
Win95A.

You can expose event handlers in your own public classes that are
public and exposed so they can be called from outside. However you
would somehow have to wrap a Windows event to provide extra
information. Or you could implement a call-back if you want to handle
a Window mouse or key event handler.

I've written a few books on programming Outlook, I don't know about
"the" book. There is no record locking in Outlook or Exchange as there
is in SQL Server for example. So you would have to implement some sort
of record locking on your own. One example of that would be to use
code that set a Boolean UserProperty to True when an item was opened
and False when closed. The code would first check that property when
opening and only set it to True if it was False. If it was already
True then someone else has the item open already and your code would
then treat the item as read-only and cancel any Write or Save events.