Monitoring for changes

  • Thread starter Thread starter Simon Woods
  • Start date Start date
S

Simon Woods

Hi

[Using Outlook 2003 (SP2)]

I want to write a little program which monitors a particular public journal
and logs date, time, old/new value, who is making the change (and
potentially other information) each time an item changes. Is there anything
in the object model to help me or do I need to do most of it myself.

Ideally, I'd like Outlook to tell me (by raising an event) just before an
item is edited so I can capture the various data I need.

Thanks

Simon
 
You can handle the ItemChange and ItemAdd events of the Items collection of
that folder. When an item is saved or added in that collection you will fire
those events. You can also monitor for items being opened (NewInspector
event of the Inspectors collection) and handle the Write event to get
changes before the save is made. That won't work with in-cell editing in a
folder view however.
 
Thanks Ken.

I must admit that I found an example of yours elsewhere which has been very
helpful.

There's still a couple of questions

1) Our company uses Exchange Server and I'm working remotely and
synchronising a task-type journal. Obviously the unread flag gets unset when
someone in the office changes a journal item and that gets reflected to me
when I synchronise. Am I able to work out who made the changes if I look
through the unread messages after synchronising?

2) Also is there an "AfterSynchronisation" type event whether it is of the
Outlook object or the specific folder I'm monitoring?

Thanks again

Simon


You can handle the ItemChange and ItemAdd events of the Items
collection of that folder. When an item is saved or added in that
collection you will fire those events. You can also monitor for items
being opened (NewInspector event of the Inspectors collection) and
handle the Write event to get changes before the save is made. That
won't work with in-cell editing in a folder view however.


Simon Woods said:
Hi

[Using Outlook 2003 (SP2)]

I want to write a little program which monitors a particular public
journal and logs date, time, old/new value, who is making the change
(and potentially other information) each time an item changes. Is
there anything in the object model to help me or do I need to do
most of it myself.

Ideally, I'd like Outlook to tell me (by raising an event) just
before an item is edited so I can capture the various data I need.

Thanks

Simon
Click to expand...
Click to expand...
 
.... also

Get I get a folder by name. I've got a recursive routine which is recursing
through my off-public folders in my favorites folder. The call

OutlookNameSpace.GetDefaultFolder

doesn't seem to offer me the top level a way into my favourites. Is there an
alternative way?

Thanks

Simon
 
Simon said:
... also

Get I get a folder by name. I've got a recursive routine which is
recursing through my off-public folders in my favorites folder. The
call
OutlookNameSpace.GetDefaultFolder

doesn't seem to offer me the top level a way into my favourites. Is
there an alternative way?
Click to expand...

OK I've sorted this one ...

OutlookNameSpace.Folders(2) is my top level Public folder

Thanks

Simon
 
Always check the store name after getting it like that or iterate the entire
Folders collection until you find the public folders. You can't depend on a
constant index value.
 
You can always check an item for PR_LAST_MODIFIER_NAME, unfortunately that's
not in the Outlook object model. So you'd have to use CDO 1.21 or Extended
MAPI or Redemption (www.dimastr.com/redemption) to get at that property.
That has the name of the last user who modified an item.

LastModificationTime tells you when an item was last modified.

There's no such event. You can handle synch end on an application wide basis
but only if your code has initiated the synch (send/receive), not if the
user has done so in the UI or on automatic synchs.
 
Thanks again Ken

Always check the store name after getting it like that or iterate the
entire Folders collection until you find the public folders. You
can't depend on a constant index value.
Click to expand...
 
It is worth noting that all the events are *not* designed for any kind of
synchronization. The work best for the UI only and are subject to be dropped
under heavy loads. Needless to say yoru code must be running all the time.
If you need to build a reliable solution, your only option is to either use
the ICS (Incremental Change Synchronization) API with MAPI or rescan the
folder contents all the time instead of relying on the events.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
 
Ken said:
You can handle the ItemChange and ItemAdd events of the Items
collection of that folder. When an item is saved or added in that
collection you will fire those events. You can also monitor for items
being opened (NewInspector event of the Inspectors collection) and
handle the Write event to get changes before the save is made. That
won't work with in-cell editing in a folder view however.
Click to expand...

Ken ... can I trouble you again ...

You say that I can use the Write event to get changes before the save is
made. I've got the event hooked up and firing okay. I've got the item which
is about to be written so have the new value. I don't understand how you
were thinking I'd get the current existing value of the item.

I know I'm being a bit slow here.

Thanks

Simon
 
You have to cache the original value of the property or properties you are
interested in. Even if you handle Item.PropertyChange or
Item.CustomPropertyChange you'd only get the name of the property that was
changed and reading its value would return the new value, not the original
value.
 
Ken said:
You have to cache the original value of the property or properties
you are interested in. Even if you handle Item.PropertyChange or
Item.CustomPropertyChange you'd only get the name of the property
that was changed and reading its value would return the new value,
not the original value.
Click to expand...

Thanks ... I thought there may be something internal I was missing. I'm
doing this through the NewInspector event Inspector.CurrentItem. Does that
sound right?

Simon
 
Back
Top