BeforeItemMove

[tobes]

Hi folks,

Having checked the forums and code samples, we're still struggling with 1
issue with our Outlook 2007 .NET (VSTO) plugin.

We have a .NET class that monitors a calendar that we've created. This
monitor class is always referenced from the main plugin, so and it's
lifecycle is the same as the plugin.

We hook the following calendar.Items events: ItemAdded, ItemRemoved and
ItemChanged, BeforeItemMoved. They all work great, EXCEPT, the
BeforeItemMoved event only works briefly and then stops working.

This monitoring class also keeps references to the calendar (MAPIFOlder)
object it's monitoring, and also a reference to the calendar.Items collection
class. Why would all the other events fire reliably, but not BeforeItemMove?

See the class code here.
http://rafb.net/p/dRcIj341.html

Could we be missing somehting? Any ideas what else we need to keep a
reference to?

Many thanks in advance.

Tobes

Note: I originally posted this on outlookcode.com, but this may be a better
place?

 

[Ken Slovak - [MVP - Outlook]]

There's a 404 for that link. Unless the relevant code is really long post it
here. A lot of people won't go to a link like that.

 

[tobes]

Thanks Ken, would I be better posting the code inline?

BTW - I'm currently reading your "Outlook 2007 Programming" book - great
stuff. That said, I still haven't solved this problem despite what you wrote
about wrappers and COM references

Tobin

 

[tobes]

In case it helps, the code is here:

http://gist.github.com/12823

(It's quite long).

Tobin

 

[Ken Slovak - [MVP - Outlook]]

You really should be declaring all the Items collections you are working
with at class level and not inside methods. I can see the GC getting rid of
those at random intervals. Or you can create wrapper classes for folders and
declare the Items collection and folder entities at wrapper class level and
put the wrapper classes in a list of some sort to keep the classes alive.
The way you're doing it I'd expect to see all of your handlers going out of
scope at some point.

In some cases it also helps to declare the COM Outlook objects as static,
although don't ever do that with objects from the CommandBars collections.