I am writing an Outlook addin that inserts content into an email, and I have a emailSent event that I would like send an event back to my server letting me know some content was shared.
Is there a way to attach some meta information to the email (or the word doc, which is what you are creating in outlook) so that I can grab that meta info so I can send it back to my server.
Right now, the only way I think I can do it is to search through the email on the send event looking for my content with regex and pull out the info i need, but that seems cumbersome, and also means I need to run the regex for every email sent, even when they haven't added my content.
There is the concept of MAPI user properties, which you can add to an Outlook item. Since Office 2007 the object model allows access to them. If your add-in must run also with older Outlook version, you should recurr to use Redemption (which I prefer also for higher office versions because it has more flexibility, albeit a greater footprint in distribution).
See UserProperties Interface on MSDN.
Related
With the Outlook UI you can add an email address to your junk-email list, you can add a domain name as trusted domain, but you can't add a domain name to your junk-email list. You must manually edit the email address in your junk-email list to achieve that, so I wrote an Add-In to do this for me, but cant find the method to do that. Apparently the Outlook object model doesn't provide anything for that.
Is there a code workaround for this fatal limitation?
That is correct. Outlook Object Model does not provide any means to access or manipulate Junk Email settings.
You can try to use Extended MAPI (C++ or Delphi) to build the MAPI server side rule that lists all the blocked senders, but it is definitely not for the faint-hearted.
If using Redemption (I am its author) is an option, it exposes RDOJunkEmailOptions object (returned from RDOSession.JunkEmailOptions, RDOAccount.JunkEmailOptions, RDOExchangeMailboxStore.JunkEmailOptions), which allow to add blocked senders using RDOJunkEmailOptions.BlockedSenders.Add.
I have developed a VSTO 4.0 Document Customisation for a custom Template which works fine and installs using ClickOnce.
However, one of the requirements I have is that the resultant documents, being the resultant .docx files, are shared with users outside of my organisation and I DON'T want them to be prompted by VSTO to install the customisation.
The external users should be able to open the document without any VSTO prompts and treat it like a usual Word document, and when the document is saved by the external user and sent back, I can open the document and the the VSTO customisation will work as expected.
This is a usability scenario where a document needs to be collaborated on by my organisation and an external organisation, but I can't expect the external organisation to install the VSTO customisation. They will typically just insert text, pictures and add review comments.
Is there any way that I can achieve this scenario?
BTW, using a Web Addin for Office 365 is not a feasible option at this stage as some of the customisation requirements cannot be achieved with the Word Javascript API.
You need to remove the link from the VSTO document before making it available to outside people. And when the document comes back you can link the customization back to it.
There's an entire MSDN article on the topic, as well as a blog article.
In a nutshell, there are two ways this can be done: from within the opened document or on the closed document.
Run the Document.RemoveCustomization method, which can be assigned to a button in the Ribbon customization, for example. This removes the links stored in Custom Document properties to the VSTO code (which is how the document, itself, finds the code when it opens), as well as any cached data.
Use the ServerDocument.RemoveCustomization method, which essentially does the same thing.
ServerDocument.RemoveCustomization(documentPath);
Re-attaching can only be done via ServerDocument.AddCustomization, logically enough.
string deployManifestPath = System.Environment.GetFolderPath(
Environment.SpecialFolder.Desktop)
+ #"\Publish\WordDocument1.vsto";
Uri deploymentManifestUri = new Uri(deployManifestPath);
ServerDocument.AddCustomization(documentPath, deploymentManifestUri);
I've created an Outlook (2010) VBScript macro that has some user-configurable settings. I've googled and checked the likely resources and can't figure out a good way to persist them. I'm currently storing them in the body of a mail item! It don't get much kludgier than that!
Should I use the Windows registry? An ini file? Or??? And whether registry, file, or???, what key/folder/??? would I use?
Just before hitting 'Post' on this I tried one more google search and hit on this: http://www.jkp-ads.com/articles/DistributeMacro08.asp.
The gist I took away was, ini file or registry are both kosher. One nice thing about VBA's use of the registry is it automatically puts "app" data in the approved place, just need to give your "app" a key. Since my data is just a big string with parsing code already in place, I used strData = GetSetting(strAppKey, strSection, strLeafKey) and SaveSetting(strAppKey, strSection, strLeafKey, strData) and voila, all is good.
The standard Outlook way of storing settings, especially if they relate to a particular mailbox/store and can be accessed from multiple machines connected to the same mailbox, is to use a hidden message stored in one of the well known folders, such as the Inbox.
The hidden MAPI messages can be accessed using MAPIFolder.GetStorage: http://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.mapifolder.getstorage.aspx
I'm using the data collection features available through Microsoft Access 2007 and Microsoft Outlook 2007 to send out an email and collect data from the recipient. The data is then stored in an Access Table.
The feature that I am using is explained here pretty well: Collecting Data Using Email
The issue that I have run into is that other than the email address, there's no way to customize the email that is being distributed. What I'm hoping to accomplish is the ability to essentially do a mail merge of sorts to personalize the email. This doesn't seem possible using the wizard approached described in the attached article. Is this something that I could accomplish via Visual Basic or some other means within MS Office.
If you've chosen the HTML-option you will get only text boxes and there is no way to customise the email if sent directly from Access. If you do not specify an email address, Access will generate the email so that you can type in the recipient - you can customise the email at that point.
If you do want all the fancy stuff (ie, customising the email, using drop downs, yes/no buttons, validation etc) then you'll need to use InfoPath as a source (again, if using Access). That's the application where you can build your form using validation and controls. The disadvantage is that the recipient needs to have InfoPath installed on their machine.
You could of course create an application to loop through your records and you can customise the HTML as much as you like then, this is probably best done outside of Office.
I'm interested in automating some reactive work I do when receiving certain emails in one of my email accounts. What I would like to have happen is:
On receipt of new email in the account
If the new email passes the "Need to React" criteria (based on body content and subject line)
3a. Scrape some content out of the email body and subject lines
3b. Populate a template form (e.g. Excel spreadsheet) with the scraped data
3c. Print the populated form and save the populated form in some folder (e.g. as a pdf)
What's the best (defined as easiest to implement by myself) approach / combination of technologies for achieving this automation?
i have not done exactly what you are asking, but I know Microsoft Outlook has a Rules engine that can take incoming messages, check for various content, and then do various actions including running applications and/or scripts.
You should look at Visual Studio Tools for Office if you are a c# person.
http://msdn.microsoft.com/en-us/vsto/default
You can write an Outlook add-on that can do pretty much everything you have outlined above.