I know how to remove a store from Outlook by using _namespace.removestore([folder]), which is working fine.
But what can I do if the store does not exist as a physical file on disc anymore? In that case every acces to the store produces a messagebox Store couldn't be found. Please select one and a file open dialog is shown. Even an assignment like store = stores[i] checks whether the file exists and causes this message.
As a user I can right click on the store in Outlook an select close [PST]. Everything is ok after that. But i would like to do this programmatically. Can anyone tell me how to do this or someone has a good website to this topic?
You can do that in Extended MAPi (C++ or Delphi) - you will need to find the PST store row in the message service table (IMsgServiceAdmin::GetMsgServiceTable) based on the store entry id, then call IMsServiceAdmin::DeleteMsgService().
You can also use Redemption (I am its author) for that - RDOPSTStore.Remove will remove the store from the profile even if the PST file does not exist.
Related
I've been trying to learn how to handle saving normal .txt files in UWP, and have realized that it's quite locked down compared to WPF, especially in the sense of what folders you can access without requesting the user to select a location. I have searched for various ways this might be possible but found no working answer.
Question Description:
I basically would love to know if this is possible, and preferably a point in the direction where I can learn how exactly to do this.
Application settings page requires user to select folder where files are saved.
Application remembers this between launches (unsure if this is possible, but I can't require the user to select the folder on every launch)
Application saves files to the specified folder.
In my understanding, this should be possible, as the user is the one specifying the location via filepicker, but is it possible to have this work between launches so that the user wont be required to re-select the save folder?
I need to figure this out, as I would like my application to support selecting attached network drives, cloud storage folders, etc.
Any help is very much appreciated, and if there are any questions I will answer them to the best of my ability.
Fow this purpose there are two access lists designed: FutureAccessList and MostRecentlyUsedList. Once the user has picked up the folder with the picker, you add it to such list and receive a token, which you save for future purpose in LocalSettings:
ApplicationData.Current.LocalSettings.Values["MyFolder"] = StorageApplicationPermissions.FutureAccessList.Add(pickedFolder);
Then later, once you want to access that folder, you can do it like this:
StorageFolder folder = await StorageApplicationPermissions.FutureAccessList.GetFolderAsync(ApplicationData.Current.LocalSettings.Values["MyFolder"].ToString());
You can't save a StorageFolder or a path to it in settings, hence the UWP app needs permissions to access the folder. Using above access lists solves this problem.
I believe you want to save user settings and keep it somewhere so that next time when they launch the application, they can use the same settings.
Please check out this tutorial from Microsoft, which describes how to do exactly that.
https://msdn.microsoft.com/en-us/library/bb397750(v=vs.110).aspx
I wanted to implement a trial version of my .NET application and I came across solutions that involved saving the dates in the app data folder. The questions I have are related to that solution and I would have commented over there but I dont have enough credits to comment.
So the solution I am following basically saves the created date and last opened date in a folder within App Data folder. If the folder did not exist before hand it creates one and after that checks the validity. That is all very good and it works.
What I want to know is:
1) What if an educated user navigates to the app data folder and deletes the folder. My solution would create a new folder and then it would be like starting over again. What would be the solution to that? I can only think of saving those credentials in different folders and checking all of them. Or maybe create that folder and the credentials during installation (which I dont know how to, I am using InstallSheild Wizard in Visual Studio). So any ideas regarding this?
2) What if originally I gave the client a 30 day trial and I was reading the dates from that folder and then validating. Then sometime later the customer buys a yearly subscription or something. How do cater that change? I could change the validation criteria in the code (I dont think that is very good either) but more importantly how can I sort of reset the app data folder? So that the validation of one year starts from the new installation/update date.
I have very little experience in developing .NET applications and even less in dealing with licenses etc. So kindly let me know a better way if there exists.
You need to hide the file in a secret folder / registry.
You can store subcription info into a file in same folder with the application. Your app will check this file first, if it does not exists, we will check the trail file.
The best solution I found was built right into Visual Studio.
Just go into properties of your project and select settings.
Add the fields you want to save. In my case they were the installed and last opened dates. And set the scope to User.
You can now access those fields by Properties.Settings.Default.%propertyname%
and do validations and set values as required.
At the end just save the settings.
The settings are saved in the hidden application data folder so they are safe from user intervention.
Sorry for bothering you - but maybe somebody can help me here!?
We are creating an Outlook 2013 VSTO Add-In to manage Corporate Signatures centrally and publish them to every user as a default signature.
We already managed to create the appropriate HTML files and store them in the correct folder.
All the same, there is no problem at all to modify the appropriate Registry keys, e. g.
HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\General
where we set the value of the "Signatures" element to the folder name of the signature file(s)
HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\MailSettings
where we set the value of the "NewSignature" and "ReplySignature" elements to the name of the default signature file
HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
where - within the appropriate user profile folder - we need to set the values of the "New Signature" and "Reply-Forward Signature" elements to the binary-converted name of the default signature file.
All these operations work perfectly fine and afterwards, we find the correct files in the appropriate folders and the correct entries in the Registry keys.
However, when creating the very first eMail after the Outlook and eMail Signature Add-In setup, users do NOT see the default signature!
Only as soon as they once open the "Signatures" dialog in the mail editor screen - and it is really enough to only open it; no need to click "OK" or so! - then they get the signature!
So my question is: is there any other Registry key or whatever that need(s) to be set so that the signature appears right away - without having to make users open the "Signatures" dialog!? Does anybody know what happens in the background of this dialog!?
What do I overlook!?
Thank you very much everyone - I truly hope you can help me here!
Best regards,
Torsten
The "9375CFF0413111d3B88A00104B2A6676" part is profile and account specific (it is profile section uid). It will be different for different users, profiles, and different accounts within the same profile .
You can see the data in OutlookSpy (I am its author) - click IOlkAccountManager, double click on the account, New and reply signature names will be in properties 0x0016001F and 0x0017001F respectively.
These properties can be set using Extended MAPI (C++ or Delphi) on IOlkAccount interface. You can also set them using Redemption (I am also its author - any language) - RDOAccount object exposes NewMessageSignature and Reply properties as well as Fields[] (can be used to set any property).
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 writing a program that deals with the logs generated by the clients server. How can I detect where the user is storing them? It feels invasive to search all files, but what if they're being stored outside of the root. Is this acceptable, what if I make the user click "detect" first? Regardless, what if they've been renamed and reformatted? Is it possible to read the server settings themselves from my external program? I want this to work on linux and windows servers. I need WC3 Extended format w/ several fields enabled that are not naturally. I also don't want it to return null if it's enabled but no log has been yet created. I don't want to force the user (assumed dumb) to play with settings.
Any ideas?
Hardcode where you expect them to be in the common case, and if they're not there, ask the user about it. Doing more "magic" than that seems like a recipe for over-complexity and mistakes.
If the user is specifying the location of the log file, then either you should have the user locate the file(s) themselves or keep track of these locations somewhere else when they are saved. You don't need to be doing a full (or large partial) drive search.