In Outlook, I'm trying to add a shared public folder (provided by Exchange) to the list of favorite folders programmatically.
I've written an Outlook-AddIn for this, that uses the Microsoft.Office.Interop.Outlook library. In this library, there's only one way to add public folders to the favorite list:
Folder.AddToPFFavorites().
The problem: When calling this method, Outlook not only adds the folder itself to the favorites list, but also ALL subfolders. In our company, we have a huge tree of subfolders attached to some folders, so I get major performance problems (Outlook completely crashes when the folder to add has too many subfolders).
Do you know a way to programmatically add only the folder itself to the favorites, without any subfolders?
The Outlook object model doesn't provide anything for that. You have to use the AddToPFFavorites method of the Folder class.
Related
I got a little pet project for work. We have three mail boxes where two of them we need to get told, when we get new emails. I wanted to make a program for that (mostly just for the learning experience) and dived into the Interop libraries of Microsoft.
The two mailboxes where we need notifications, I first need to locate those mailboxes and then I can assign things like event listeners, etc. But I don't know how to achieve this.
To find the root, I do this:
outlookNameSpace = outlookApplication.GetNamespace("MAPI");
And then I can start dragging out folders and assign them to variables like so:
supportInbox = outlookNameSpace.Folders["Omitted"].Folders["Inbox"];
pensionInbox = outlookNameSpace.Folders["Omitted"].Folders["Inbox"];
But the code says that it cannot find the folders with the names (that I replaced with "Omitted" just for sake of privacy).
What am I doing wrong?
If you are accessing multiple Mailboxes, you have to first ensure that they are both loaded in the current Outlook profile. Otherwise, you need to ensure that the currently logged on user has delegate access to the Mailbox you want to access and use the NameSpace.GetSharedDefaultFolder method to open their Inbox. However, you only have access to the Inbox with Delegate scenarios.
Otherwise, to get specific folders for a specific Mailbox in the current profile, you can try this approach:
How to: Obtain a Folder Object from a Folder Path
http://msdn.microsoft.com/en-us/library/ff868990(v=office.15).aspx
You may also need to loop through NameSpace.Stores to get a specific Store object for the Mailbox, and access a folder via Store.GetRootFolder or Store.GetDefaultFolder.
I have a very simple use case.
1) I have 4 config files which are needed for the application to start.
When I publish my application these files should be exported by default along with it. How can I do this ? Where should the files be stored so that they are available when the pplication is installed?
The users of this application should be able to edit and access these files.
I have seen the option of saving it using string source = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
I have tried adding these as resources, but these files need to be editable, hence cannot be in exe.(Reference is this question)
Please comment if you need additional information.
If you're building the installer in Visual Studio, you can add those files as Content and it should be automatically included in the installer when it's built.
You create installers in Visual Studio by adding a Setup Project to the solution.
Link to tutorial on MSDN: http://msdn.microsoft.com/en-us/library/vstudio/19x10e5c(v=vs.100).aspx
I recall it should automatically add all Content items automatically, but I'm a bit rusty. Here's more detail on how to add items to your installer, including desktop shortcuts and such:
http://msdn.microsoft.com/en-us/library/vstudio/z11b431t(v=vs.100).aspx
Good luck!
There are meny ways to do whay you want to do. the main question is why do you want to do it?
if you have a normal program for personal use you can simply link it to the needed file, meaning using the file without actual knowledge that it's there.
if it's for a task then you can zip them together, that way you'll know they are together, without adding them as resource.
for other kind of use, or if you have to add them as resources, just add them like shown here
for more reading on what do you need and how to do it i have here linked vs. Embeded resources
good luck
I have a need to add tasks that I programmatically create into a folder within Outlook.
I have code that creates a task and I also have code that creates a folder. This works fine.
Now the tricky part, how can I add my newly created task (the task is an object in memory at this point) to my newly created folder (Or just a folder in general)?
At this point I am looking to just add them to a folder, however in Outlook I am able to create a 'folder' like item that I can create tasks in (see attached screenshot). I would love to really be able to do this programmatically instead of a folder.
Does anyone have examples or documentation that could possible point me in the right direction?
If you have a reference to a Folder, you can use Folder.Items.Add to create a TaskItem in that Folder.
If you used Application.CreateItem, then you should use TaskItem.Move to move the item into a specific Folder.
I'm trying to develop an AddIn - or rather, just a proof-of-concept for now, to see if what I have in mind is actually even possible - for Outlook (2010, to be exact), in .NET/C# and I'm facing the following problem:
The AddIn is supposed to offer a new custom Folder (on the top level of the hierarchy, i.e. next to all the other main items, like Tasks, Calendar, Contacts, etc.) in which to offer items to the user. So I figured that in the Startup method of the AddIn I could simply do something like
Outlook.Folder parent = inBox.Parent as Outlook.Folder;
Outlook.Folder myCustomFolder = (Outlook.Folder)parent.Folders.Add("My Custom Folder");
... and that does in fact work. However, there's a problem after quitting Outlook and starting it again. Since the folder is being persisted by Outlook, it is still there the next time Outlook launches and initializes the AddIn again, so the creation of the folder fails because an object of the same name already exists. But I don't see any way how to tell that this is "my" folder from last time.
I don't want to rely on its name to identify the folder (that's just too unreliable to even consider; users might want to rename it, other AddIns might exist that create a folder of the same name, not to mention localization problems etc.), but what else can I use to determine that the custom folder has already been created?
I would either have to be able to somehow add a "tag" do the folder so I can later recognize it as "mine" - or alternatively would need some kind of id that uniquely identifies the folder (and which remains constant even between launches of Outlook!) so I can recognize it by that.
I have been looking at the EntryID and StoreID fields of the [MAPI]Folder object, but from the (sadly, not very detailed) description at the MSDN, I'm not sure if I can rely on them, because apparently they can change under certain conditions.
Any suggestions?
Unless the folder is deleted and then recreated, the entry won't change. But it won't be the same folder anyway - just another folder that might have the same name.
What Outlook does is store the special folders' entryids on the root IPM folder and/or the Inbox folder.
Since you cannot set named properties on folder in Exchange and you cannot just pick your own property tag without risking running into a conflict, create a hidden message in the Inbox folder(which is always present in the default store) and store the folder entry id along with whatever else configuration properties you might need. To make sure your config hidden message is unique, pick a unique mesage class, e.g. IPM.Note.MyCompany.MyAdddin.Config.
Hidden messages can be accessed using MAPIFolder.GetStorage in the Outlook Object Model or RDOFolder.HiddenItems in Redemption.
I'm working on an application that shows a listing of files and folders within a Sharepoint document library. The file/folder list is created based on the SPList's RootFolder.SubFolders and .Files collections.
Is there a way to filter out the "Forms" folder from the results, without hard-coding a check for a folder called forms?
You could check if the folder does not have an associated list item, i.e. if SPFolder.Item is null. Otherwise, hard-coding the name "Forms" should be ok as this does not change across different language versions of SharePoint.