i have the following situation for my Add-In (Office >= 2010):
I want to add some custom properties to an Outlook.MailItem (property must be mail associated) while the mailtext is written.
If this mail is sent i want to grap the send event and get the previously set properties again, doing something and removing the properties and continue sending.
Problem if i use PropertyAccessor:
I use it as follows to save the property while writing the mail:
string propTag = "http://schemas.microsoft.com/mapi/string/{00020329-0000-0000-C000-000000000046}/test_property"
mailItem.PropertyAccessor.SetProperty(propTag, value);
And to read the property again on sending the mail:
string propTag = "http://schemas.microsoft.com/mapi/string/{00020329-0000-0000-C000-000000000046}/test_property"
string readProperty = mailItem.PropertyAccessor.GetProperty(propTag);
works if cached mode is enabled on exchange
works NOT if cached mode isn't enabled... i can't find the previously setted properties anymore (Exception with unknown property is thrown)
OutlookSpy (http://www.dimastr.com/outspy/home.htm) can find the property on sending so does anyone knows how to read the properties in a different way?
I would thank you very much for every help.
You need to call Save if you want your changes to be persisted.
When I iterate through all Outlook folders (in a C# Add-In) I see folder names like:
Yammer Root
Sync Issues
Subscriptions
These folders are not visible in Outlook. I like to check in my code if the folder is visible or not but I don't find a property like Hidden or Visible.
MAPIFolder folder has properties like:
folder.DefaultItemType
folder.Name
but not hidden.
How can I find out in my c# Add-In if folders are hidden or not?
You will need to read the PR_ATTR_HIDDEN MAPI property (DASL name http://schemas.microsoft.com/mapi/proptag/0x10F4000B). You can read it using MAPIFolder.PropertyAccessor.GetProperty.
You can see that (and other) property using OutlookSpy (I am its author) - click IMAPIFolder button.
At least on my machine I never retrieved a value for PR_ATTR_HIDDEN for all folders. I could not find out the reason although in OutlookSpy the value is true for the hidden folders.
Code:
var rootFolder = outlook.Session.DefaultStore.GetRootFolder();
foreach (Folder folder in rootFolder.Folders)
{
try
{
bool isHidden = folder.PropertyAccessor.GetProperty("http://schemas.microsoft.com/mapi/proptag/0x10F4000B");
// never reach this line
}
catch (System.Exception ex)
{
// always exception: value is not available
}
}
My workaround: If you want to retrieve the folders as they are displayed in Outlook you can use PR_CONTAINER_CLASS_W and compare it with IPF.Note or IPF.Imap.
Sample:
const string PR_CONTAINER_CLASS_W = "http://schemas.microsoft.com/mapi/proptag/0x3613001F";
string containerClass = folder.PropertyAccessor.GetProperty(PR_CONTAINER_CLASS_W);
bool isVisible = string.Equals(containerClass, "IPF.Note")|| string.Equals(containerClass, "IPF.Imap");
Currently I have a Exchange public folder that has assigned Custom Form. One of the many user defined fields on the form is set to be of Currency. For some reason doesn't matter what I do, I can't set Currency field pragmatically.
I have created a separate folder and simple custom form where one field is of type Currency as below:
Custom Form Setup
Then I am able to create Post Item and save it to the folder that has test custom form assigned but unfortunately I can't seems to set TestCurrency extended property:
var JobsSearchFilter =
new SearchFilter.IsEqualTo(FolderSchema.DisplayName, JobsFolderName);
var JobsFolder =
service.FindFolders(WellKnownFolderName.PublicFoldersRoot, JobsSearchFilter, new FolderView(1)).Single();
var JobsSearchFilter =
new SearchFilter.IsEqualTo(FolderSchema.DisplayName, jobFolderName);
var ewsFolderUniqueId =
JobsFolder.FindFolders(JobsSearchFilter, new FolderView(1)).Single().Id;
var postItem = new PostItem(service)
{
ItemClass = "IPM.Post.EWSTestingForm",
Subject = "Testing Custom Forms"
};
postItem.SetExtendedProperty
(new ExtendedPropertyDefinition
(DefaultExtendedPropertySet.PublicStrings,
"TestText",
MapiPropertyType.String), "TestTextValue");
postItem.SetExtendedProperty
(new ExtendedPropertyDefinition(
DefaultExtendedPropertySet.PublicStrings,
"TestCurrency",
MapiPropertyType.Currency), 1200.000);
postItem.Save(ewsFolderUniqueId);
Do Currency extended property fields need special treatments? All other fields seem to work (text, booleans etc)
Interestingly as I investigate more, it turns out that extended property of MapiPropertyType.Currency is being posted to the Exchange Server as I can retrieve it right away but custom form doesn't pick up the value. It appears to be that the reason why it is not picking it up is because EWS creates extended property of type PT_I8 instead of PT_CURRENCY (got those via OutlookSpy). It is likely that it is a bug in EWS for mapping MapiPropertType.Currency to correct Exchange mapi type...
Extended Properties set via EWS vs User Input in Custom Form
I have developed one outlook add-in, that has to be On or Off.
to do that i have declared one static variable as shown below,
ThisAddIn.cs
public static bool isAddInOn = false;
RibbonButton.cs
private void btnRibbon_Click(object sender, RibbonControlEventArgs e)
{
if (ThisAddIn.isAddInOn )
{
ThisAddIn.isAddInOn = false;
btnRibbon.Label = "Disabled";
}
else
{
ThisAddIn.isAddInOn = true;
btnRibbon.Label = "Enabled";
}
}
It is working. But the static variable reset again when i close outlook and open it again. That means when i open outlook by default my add-in is in disabled state.
I just want to store that value at some place. so i can check that value when outlook reopened.
Scenario:
1) open outlook
2) Enable add-in by clicking on its logo (that is in ribbon)
3) now close the outlook
4) when i open outlook again it must enabled
so how can i achieve this ?
There are several techniques you can use to achieve this result. For sure your settings must be serialized to some storage/deserialized during startup of add-in.
One of possible solution could be to use registry for that (in this case probably HKCU (Current user, then it will be private for each user using your add-in) and no special permission is needed.
For storing variable:
public void StoreInRegistry(string keyName, string value)
{
RegistryKey rootKey = Registry.CurrentUser;
string registryPath = #"Software\YourCompanyName\YourAddInName";
using (RegistryKey rk = rootKey.CreateSubKey(registryPath))
{
rk.SetValue(keyName, value, RegistryValueKind.String);
}
}
For reading variable:
public string ReadFromRegistry(string keyName, string defaultValue)
{
RegistryKey rootKey = Registry.CurrentUser;
string registryPath = #"Software\YourCompanyName\YourAddInName";
using (RegistryKey rk = rootKey.OpenSubKey(registryPath, false))
{
if (rk == null)
{
return defaultValue;
}
var res = rk.GetValue(keyName, defaultValue);
if (res == null)
{
return defaultValue;
}
return res.ToString();
}
}
Such stored/retrieved variable should be used during add-in initialization to set your properties. So modification could look like:
ThisAddin.cs
public static bool isAddInOn = ReadFromRegistry("MySetting1", "0") == "1";
RibbonButton.cs
private void btnRibbon_Click(object sender, RibbonControlEventArgs e)
{
if (ThisAddIn.isAddInOn )
{
ThisAddIn.isAddInOn = false;
btnRibbon.Label = "Disabled";
}
else
{
ThisAddIn.isAddInOn = true;
btnRibbon.Label = "Enabled";
}
StoreInRegistry("MySetting1", ThisAddIn.isAddInOn ? "1" : "0");
}
Other options could serialization to file - some class with settings serialized to i.e. isolated storage, database (local or central) etc.
I've used several methods over the years to store configuration data for users.
Properties.Settings.Default.Properties, so writing in the application project properties. It's solid, never had an issue with it, for hundreds of users over several years.
Local config files in text, so writing to a known area for the user with fallback. In a stable environment, one can choose the home area for the user, and read/write to the local config file, which also makes it accessible to support if it breaks and needs manual changes. As a fallback, one could write to the local temp folder.
Registry is an option i have not used in this case, but it is likely to be a good choice.
Performance is likely a key concern considering it will impact the UI for users. Another concern is ease of use for the developer. For both, my choice would be setting it in the application's properties, where reading and writing is very simple and handled within code, and likely very fast.
Write
Properties.Settings.Default.PropertyName = propertValue;
Read
var propertValue = Properties.Settings.Default.PropertyName;
2018 UPDATED ANSWER
The recommended way to achieve this is now to use the already configured settings files in your project's properties. These files are auto-generated when create your project :
And open the following window when clicked :
You can access your settings value programmatically into Properties.Settings.Default.Properties anywhere.
The header bar at the top of the Settings page contains several controls:
Synchronize
Synchronize restores user-scoped settings that the application uses at run time or during debugging to their default values as defined at design time. To restore the data, remove run-time generated application-specific files from disk, not from project data.
Load Web Settings
Load Web Settings displays a Login dialog box that enables you to load settings for an authenticated user or for anonymous users. This button is enabled only when you've enabled client application services on the Services page and specified a Web settings service location.
View Code
For C# projects, the View Code button enables you to view the code in the Settings.cs file. This file defines the Settings class, which enables you to handle specific events on the Settings object. In languages other than Visual Basic, you must explicitly call the Save method of this wrapper class in order to persist the user settings. You usually do this in the Closing event handler of the main form. Following is an example of a call to the Save method:
C#
Properties.Settings.Default.Save();
For Visual Basic projects, the View Code button enables you to view the code in the Settings.vb file. This file defines the MySettings class, which enables you to handle specific events on the My.Settings object. For more information about accessing application settings by using the My.Settings object, see Access application settings.
For more information about accessing application settings, see Application settings for Windows Forms.
Access modifier
The Access modifier button specifies the access level of the Properties.Settings (in C#) or My.Settings (in Visual Basic) helper classes that Visual Studio generates in Settings.Designer.cs or Settings.Designer.vb.
For Visual C# projects, the access modifier can be Internal or Public.
For Visual Basic projects, the access modifier can be Friend or Public.
By default, the setting is Internal in C# and Friend in Visual Basic. When Visual Studio generates helper classes as Internal or Friend, executable (.exe) applications cannot access the resources and settings that you have added to class libraries (.dll files). If you have to share resources and settings from a class library, set the access modifier to Public.
For more information about the settings helper classes, see Manage application settings.
Settings grid
Settings Grid is used to configure application settings. This grid includes the following columns:
Name
Enter the name of the application setting in this field.
Type
Use the drop-down list to select a type for the setting. The most frequently used types appear in the drop-down list, for example, String, (Connection string), and System.Drawing.Font. You can choose another type by selecting Browse at the end of the list, and then selecting a type from the Select a Type dialog box. After you choose a type, it's added to the common types in the drop-down list (for the current solution only).
Scope
Select either Application or User.
Application-scoped settings, such as connection strings, are associated with the application. Users can't change application-scoped settings at run time.
User-scoped settings, such as system fonts, are intended to be used for user preferences. Users can change them at run time.
Value
The data or value associated with the application setting. For example, if the setting is a font, its value could be Verdana, 9.75pt, style=Bold.
Documentation link
Reading settings
Writing settings
Settings can be stored as a hidden (associated) item in a folder, such as the Inbox or the Calendar folder. For example, Outlook stores the list of categories as a hidden item in the Calendar folder. POP3 message ids are stored in a hidden item in the Inbox. The advantage of the hidden items is the roaming capability - Exchange mailbox user can see the data from any computer.
You can see the hidden items in OutlookSpy (I am its author) - click IMAPIFolder button, go to the "Associated Contents" tab.
Programmatically, such items can be accessed using MAPIFolder.GetStorage in the Outlook Object Model.
I am programmatically creating a search folder via Search.Save method. After I save the search (it creates a new folder in the Search Folders directory), I would like to set to focus on this newly created folder such that the view changes to this folder.
This is the code I have thus far....
searchFolders = inboxFolder.Store.GetSearchFolders();
foreach (Outlook.Folder folder in searchFolders)
{
if (folder.Name == "Expiring Retention Policy Mail")
{
folder.ShowItemCount = Microsoft.Office.Interop.Outlook.OlShowItemCount.olShowTotalItemCount;
//folder.SetCustomIcon(new Bitmap(32, 32));
folder.Display();
}
}
When I do folder.Display() it opens up an entirely new inspector window... I don't want this to happen, I simply want to select it (like via set focus?) and have it viewed in the same inspector window it exists in. Does anybody know how to do this?
Thank you.
This should work for you...
Get access to your Application object (or from the main add-in class). And then
this.Application.ActiveExplorer().CurrentFolder = folder;
i.e. you can use CurrentFolder of the ActiveExplorer
Of course, always make sure to properly release your COM objects (the ones that need releasing) - and
you should never do it like I did here (for simplicity) - i.e. chaining properties like
that. Save each (property) into a variable, and release via
Marshal.ReleaseComObject on your way out.