I need to know if it is possible to force a user to use a particular theme (No theme) in Outlook 2010 and also restrict them from being able to change the theme..
There seems to be quite a lot of solutions for outlook 2007 on the internet but nothing for 2010.
Thanks
The Outlook object model doesn't provide anything for that.
You can read the current Office theme by looking at the value of HKCU\Software\Microsoft\Office\14.0\Common.
Related
I have built an VSTO Outlook Add-in which creates customs emails based on some input events. The form region of these emails consist of an embedded WPF form which contains TextBoxes, ListBoxes, ListViews, buttons and things like that.
What happens is that sometimes the embedded WPF form is not displayed within the form region. I say "sometimes" because from my development machine under Visual Studio 2019 and .NET 4.5, it is always correctly rendered and displayed however if I create a new clean virtual machine (no Visual Studio 2019 installed on it), with only Outlook 2019 or 365 installed plus my add-in and .NET Framework, then WPF form is not shown (the form region appears empty/blank).
I have tried to compare differences between the development machine and the clean virtual machine to see if i need to install some type of complement in order to Outlook be able to render the WPF form but I am not be able to discover what is missed. I tried to install Visual Studio 2010 for Office runtime but even with that installed the form region containing the WPF form is not shown.
I don't know if maybe there is some Office key in the registry I must enable in order to make it work. Also I have taken a look at Outlook options to see if there are something to adjust but I haven't seen anything regarding to Outlook render engine.
I have not posted any piece of code here because I think it is not a code related issue since it is working perfectly in my development machine. I think it is something related to Outlook itself.
Any ideas on what can be happening?
It seems you need to modify the add-in installer to include all prerequisites and do the required windows registry modifications. See Deploy an Office solution by using Windows Installer for basics.
As for the form regions, you may find all the required information in the Specifying Form Regions in the Windows Registry article.
Finally I have solved, the problem was that in the deployed machine a key was missing under below path:
HKEY_CURRENT_USER/Software/Microsoft/Office/Outlook/FormRegions
I'm using Outlook 2010. Via the Developer ribbon, I see that I'm able to script Outlook using VBA. I'm also aware that you can create Outlook addins through COM that can pretty much have anything as their source language (C# / .NET included).
However, is there any way to actually code extensions to Outlook using built-in Outlook functionality using C#, rather than VBA? If not, are there any plans for Microsoft to allow this in future versions of Outlook?
I'm not sure what you mean by "built in" functionality. Addin can access anything VBA can access AFAIK.
Are you talking about converting the VBA editor to c sharp?
Few question about VSTO project I don't understand:
Registration - unlike native Office Plugin, where I've an installation project, how does the deployment work in managed add-in? After building the project, I do have the necessary entries in the registry that define the plugin (HKCU\Software\Microsoft\Office\Outlook\Addins...). Where is the code that perform this registration?
Also, why in the HKCU? I'd like the plugin to be defined for all users (in HKLM). How do I change that?
How does Visual Studio know to start Outlook, when I press F5? In the property page for the project, under the debugging tab, the 'Start Option' is set to 'Start project'. Who tells Visual Studio that starting the project means starting Outlook?
Looking for more materials about VSTO. Can you recommend a resource?
A few answers
1. Basically the same for a managed project except that the Reg entries point to the .MANIFEST file, which in turn identifies the dll of the addin assembly.
Ohhh. this is a LONG story, there's lots of info on the web about it. Google "registering an addin for all users".
Short version is that it's possible, but requires some really weird and difficult to explain registry shinanigans.
If you've created an Outlook addin property, then by virtue of that project type, VS knows what to do on start.
I've never found a good definitive source for vsto material. Google's been my best friend for that kind of info. Andrew Coates has a pretty decent list here though
http://blogs.msdn.com/b/acoat/archive/2007/08/02/vsto-resources.aspx
I have no explicit information but currently I'm working through http://msdn.microsoft.com/en-us/library/ff937654.aspx which so far has been a great source of information. Please let me know if this worked out for your Outlook project.
Can someone give me a quick explanation of when I would use Visual Studio 2008 Outlook 2007 Ad-In project type? and how would that compare to developing a bunch of outlook macros directly in outlook?
Basically, I want to have some sort of application read email (with attachments) from a pop3 email box, do some filtering/editing/validation of the subject/sender/content and then if certain conditions are met, save the attachments to a local file, and then add an entry into an SQL server database table (i.e. date/sender/subject/message).
Seems there are at least 10 different ways to do this....so between an outlook macro and a VS Office Project, how do I pick?
I am not clear, if I create this solution as a Visual Studio outlook add-in, where does it run? Is it loaded into outlook, does it run as a separate process and communicates back and forth with outlook? if outlook is not running, does it start it?
An Outlook Add-on is a compiled component that uses the Outlook API to perform the tasks you need. A macro/VB script is an interpreted script that actually uses the same API. The add-on approach is better if you want to deploy your functionality.
When you work on an Outlook add-on in Visual Studio, you'll be creating a .NET component, which integrates into the Outlook application, which is written in C++ so uses COM. You'll have to be careful about managed/unmanaged types and releasing objects you retrieve from Outlook.
I have recently completed just such a tool, but I chose to use Add-in Express (http://www.add-in-express.com/). These guys provide a layer of abstraction over the [challenging] Outlook API and also provide some excellent support if you're stuck.
In my case, with Add-in Express, I "run" by setting Outlook as the application command to run, in the Project properties. Add-in Express sorts out the installation of the add-on within Outlook. So when I press "Run", Outlook starts and my add-in is displayed, which may be debugged in the normal fashion. I'm not sure how VSTO (Visual Studio Tools for Office) works in this respect - or at least, I can't remember.
This is an example of an outlook add-in..
Personally, I don't see macros distributable.
I want to create a custom Addon/plugin for Outlook 2003, to support integrated functionality with a task management system.
I am unable to find many good development resources for the same.
Can someone please explain Outlook 2003 architecure and development of a plugin.
Good links/resources are also welcome.
Here is a tutorial on outlook architecture getting started building Outlook 2003 plugins from MSDN:
http://msdn.microsoft.com/en-us/library/aa289167.aspx
There is also a huge list of resources here: http://www.microeye.com/resources/res_tech_vsnet.htm
Good luck!
What you want can be done.
The bottom line is that you need to use Visual Studio 2005 or Visual Studio 2008 plus Visual Studio Tools for Office (VSTO) plus Outlook 2003 (of course) to build an "Adddin" for Outlook.
Addins are quite complicated to write mostly because Outlook has eccentricities that are not well documented. For example, a method Outlook.MailItem.GetHashCode() is not always the same even for the same object despite what you might expect from something as seemingly absolute as a 'HashCode' for an object. Knowing that and many other quirks of the VSTO+Outlook API are for what the professionals get paid. There are MANY quirks. If you are learning then you will need to start with the resources Gdeglin has provided.
Also look at the MSDN VSTO forum:
http://social.msdn.microsoft.com/Forums/en-US/vsto/threads <- very active!
And Outlook code: http://www.outlookcode.com/
Also here is a Google search on MSDN for various VSTO 'tips'.