Where do I put Custom session information on a VSTO C# Outlook Add

[rchf]

Yet another newbie question. I am looking for a place to put one of my
custom objects to preserve state of the Add-in while Outlook is being
executed. This object would basic things like UserID so I can check they
have logged in. Ideally I'd also be able to put other custom objects in the
same place so I would not have to constantly deserialize/serialize objects
to/from the filesystem as various buttons are pressed.

Also - how does one get to the UserID on Windows XP from within VSTO in C#?

Many thanks,
Richard

P.S. I have looked through help under the topics of: globals, state,
session, add-in, application, and more. So I have given it a solid RTFM
attempt.

 

[Ken Slovak - [MVP - Outlook]]

It depends on what you're trying to preserve.

If it's text and/or Boolean data just use a collection of some sort or an
array or dictionary or whatever.

If it's actual Outlook objects then a collection but be careful to release
all object references when needed.

If the data has to be preserved between Outlook sessions then you can use an
INI file or a resource file or configuration strings. I prefer to use
something stored inside the addin resources so the data can't be messed
with.

I'm not sure what you mean by UserID, do you mean the Windows logon name?

 

[rchf]

Hi Ken,

Thanks for the reply.

What I am trying to do is preserve information on a custom object without
recourse to the filesystem. For example, a encryption key derived from a
user's logon is NOT to be saved to the filesystem but can be kept in an
object in working RAM while Outlook is running. Even if it was not a key -
going to the filesystem for everything repeatedly takes too long.

The problem is whenever a method goes out of scope the object I create with
the "custom information" I want to preserve (e.g. encryption key), no longer
has any pointers to it and is garbage collected. The next time a "event"
occurs I cannot get access to the "custom information" because: 1. I don't
have a pointer to the object and 2. the object has been garbage collected.

Even if I create some collection for my custom object(s), that collection
needs to be pointed to by some persistent Outlook object that is generally
addressable by my methods or I won't be able to retrieve a reference to said
custom object. Where can I put that pointer to my "custom information" so
that it sticks around and can be retrieved but is NOT in the filesystem.

Its a total newbie question but I can't find a way of getting the 'extent'
of my custom objects to last beyond the 'scope' of my methods.

Thanks for your help,
Richard


--
"Lisp doesn''''t look any deader than usual to me."

- David Thornley, reply to a question older than most languages

It depends on what you're trying to preserve.

If it's text and/or Boolean data just use a collection of some sort or an
array or dictionary or whatever.

If it's actual Outlook objects then a collection but be careful to release
all object references when needed.

If the data has to be preserved between Outlook sessions then you can use an
INI file or a resource file or configuration strings. I prefer to use
something stored inside the addin resources so the data can't be messed
with.

I'm not sure what you mean by UserID, do you mean the Windows logon name?

 

[Ken Slovak - [MVP - Outlook]]

You must declare your collection at a class level that retains scope for as
long as you need that collection. For example, in a VSTO addin I might
declare a sorted list to use as a collection for my Inspectors or various
items, I declare that in the ThisApplication class (ThisAddin for VSTO 2005
SE). If I need an object to be retained inside a lower level class I would
declare that object at the class level inside that class.

 

[rchf]

Thank you Ken. I had been confused by the sites that talked about
ThisApplication and did not know about ThisAddin.

I found a cludge that also works. Apparently, VSTO's Connect class instance
is persistent during an Add-in's operation and of course allows the user to
customize it. Since Connect is from whence all events are dispatched it is
possible to pass a pointer to the Connect instance into event_handlers and
thereby give event handlers access to your custom objects which persist
throughout the session.

But the ThisAddin approach is MUCH better cleaner - thank you.

-Richard



--
"Lisp doesn''''t look any deader than usual to me."

- David Thornley, reply to a question older than most languages