One common question developers have asked is how they can extend the view area of Outlook to display additional information related to the contents of a folder. Our solution to this problem is to use a Folder Home Page along with the Outlook View control to enable you to customize the look and feel of a folder, while still displaying folder information.
One example of an Outlook folder home page that ships with Outlook is the Outlook Today page, which is accessible by clicking on the top most folder in your default store.
Lately, developers have been interested in how they can leverage some of the new .NET Framework 3.5 enhancements like WPF in this space. Hülya Pamukçu has recently posted an article over on the CSD End-to-End Team Blog about this very subject. In the article Hülya covers how to host WPF controls inside a folder home page and how to leverage the Outlook View Control in the space at the same time.
As part of SP3 for Outlook 2003 (and included in SP1 for Outlook 2007) we’ve made a change to the way command line parameters are parsed to ensure Outlook is always doing the right thing. As part of this change, a less common way of attaching files to new e-mail messages through command line parameters with Outlook may be broken in some solutions.
Previously, Outlook under some circumstances would handle an implicit command line parameter without a switch. For example, if a command line argument was provided without a switch, and was a path to a folder in the file system, Outlook would treat the argument with an implicit /select switch flag, displaying that folder in the Explorer window. If the argument was a path to a file on the file system, Outlook would use an implicit /a switch and attach the file to a new message.
As part of making sure that our command line parameters were handled in a predictable manner, we removed the implicit logic in these service packs. You must now explicitly specify the appropriate switch before the path to a folder to display or file to attach. If a solution calls Outlook using an argument without a switch or with an invalid set of switches, the following error is displayed:
For more information on the valid command line switches that are supported by Outlook, take a look at our online documentation for command line switches.
There are a few applications that I’m aware of that have already run into this problem. I wanted to blog about it and make sure everyone knew what was going on and how to fix a solution that no longer works as expected. Command line parameters should always be preceded by a command line switch specifying what to do with the parameter.
Edit: This change was included as part of Outlook 2007 RTM, not just SP1 as I originally stated.
Stephen Griffin is asking this question over on his blog. If you're using Exchange Client Extensions and haven't been able to port your solution over to an add-in (for a reason other than budget concerns or legacy support), now would be a good time to chime in and let him know why.
If you’ve started to take advantage of the new Outlook controls on form regions in Outlook 2007, you may have noticed something strange. None of the controls have common properties you would expect all controls to have: Visible, Width, Height, Top, Left, etc. You might be thinking we missed some obvious test case here, but you’d be wrong.
These properties do in fact exist on the controls. However, because of a complexity of COM and Office dependencies, the properties do not show up in the type library exposed by Outlook.
Each of the Outlook controls (they all start with Olk in the type library) also implement the Control interface from fm20.dll. This interface includes all common properties, including Height, Width, Top, Left, Name, Parent, TabIndex, TabStop, Visible and more.
If you are using a language that supports late binding for COM objects, you can just reference the property directly and everything will work as expected.
If you’re writing managed code, or other code which requires explicit definitions of the properties, you will need to cast the control object to the Control interface from fm20.dll to read or write these properties. For example, if you’re writing in C#, you would need to do something like the following:
using Outlook = Microsoft.Office.Interop.Outlook;
using MSForms = Microsoft.Vbe.Interop.Forms;
public void BeforeFormRegionShow(Outlook.FormRegion FormRegion)
{
// Find OlkButton1 and make it invisible
MSForms.UserForm canvas = FormRegion.Form as MSForms.UserForm;
Outlook.OlkCommandButton button1 =
canvas.Controls.Item("OlkButton1") as Outlook.OlkCommandButton;
//button1.Visible = false; // can't do this, it doesn't compile
MSForms.Control ctrlButton1 = (MSForms.Control)button1;
ctrlButton1.Visible = false; // this works!
}
We tried to find a way to combine these two interfaces together, but because Outlook doesn’t have a dependency on the Microsoft Forms library, it wasn’t feasible to make it work right. There is at least a work-around for developers who need to access these properties.
You can also access additional Outlook-specific properties on controls by casting the control to the OlkControl interface in Outlook. This interface provides you with the ability to control layout settings for how the control will behave on the form. These properties can be set either at runtime or design time, as long as you set them before the layout is calculated (which occurs just after BeforeFormRegionShow).
I just noticed that the official site for the 2008 Microsoft Office System Developer Conference has gone live. For the first time this year, the conference is open to the public, so any and all Office System developers can attend. The conference will be in sunny San Jose, Feb 10-13, 2008 (and the weather should be a welcome change from Seattle's rainy Feburary weather).
The converence will provide an oppertunity for architects, developers, industry experts, and Microsoft insiders to come together to discuss developing solutions around the Office System. Should be a good event for everyone with an interest in developing solutions for the current and next generations of the Office System.
Registration will open in October. For more details about the event, check out www.odc2008.com.
If you are running Office Outlook 2007 and Windows Vista together, you might be running into the Windows GDI limit and experiencing issues with Outlook. After your Windows Vista-based computer has been running for an extended period of time, with Office Outlook 2007 running, Outlook may stop updating the screen correctly. For example, you may experience any of these symptoms:
- Parts of the Outlook window become blank
- Parts of the Outlook window become transparent
- Views are draw incorrectly or incompletely
- Icons may disappear
- Toolbars may disappear
These symtoms are more likely to occur if you are running the Outlook Appointments gadget, 3rd party Outlook gadgets that query for calendar appointments, or a program that synchronizes your calendar.
You can confirm that Outlook has hit the limit on GDI objects by using Task Manager to view the number of GDI objects in use by Outlook.exe. To do this, follow these steps:
- Press CTRL+ALT+DEL.
- Click Task Manager.
- Click the Processes tab.
- Click View, then Select Columns.
- Check GDI Objects and click OK.
- Click the outlook.exe process, and scroll to the GDI Objects column.
By default, Windows Vista limits processes to 10,000 GDI objects. If Outlook is shown as using close to 10,000 objects, then this issue may be the cause of the symptoms you are seeing.
Workarounds:
To work around this issue, you can a) log off Windows, and then log on to the computer again, or b) restart the Outlook process. It may be necessary to force quit Outlook if the process does not shut down normally. To do this, follow these steps:
- Press CTRL+ALT+DEL.
- Click Task Manager
- Click the Processes tab.
- Click the outlook.exe process
- Click End Process, and then click End process.
- Launch Outlook again from the Start menu.
Update Information
This issue is related to a similar issue reported with Explorer.exe showing similar symptoms. The fix for both issues is the same, and is avaialble from http://support.microsoft.com/kb/932406.
Are you a managed add-in developer for Outlook 2007, who's been wondering where the documentation on the Outlook 2007 PIA might be? Well look no further, because the Outlook 2007 Primary Interop Assembly Reference is now avaialble on MSDN. No longer will you need to use the VBA reference shipped with Outlook 2007 when writing your managed code. This reference provides help context and information on the classes, properties, methods, events, and interfaces provided in the Outlook PIA.
Even better, if you are using Visual Studio 2005 or Visual Studio 'Oracs' you can get an integrated help experience for Outlook object model types simplying by placing the cursor on an Outlook type (for example, Items.IncludeRecurrences) and pressing the F1 key. For this to work, you do need to make sure Visual Studio is configured to try online help, either through the "Try local first, the online" or "Try online first, then local" setting in the Visual Studio help engine.
One advantage of the help being online on MSDN is that you can provide feedback and ratings on individual topics in the PIA reference by clicking the "Click to Rate and Give Feedback" link at the top of each help article. If the article really helps you out, give it 5 stars. If you're still stuck and need more information, write a constructive comment that indicates how we can better help solve your needs.
Wes has a good post over on his blog explaining another common problem that a lot of Outlook solution developers run into:
Imagine we have some code in an Outlook addin that looks similar to code below. Does anyone see anything wrong with it? It simply places a button on the menu bar and shows a message box when the button is clicked. The code works for sometime but then all of a sudden the button mysteriously stops working. What gives?
using Office = Microsoft.Office.Core;
using Outlook = Microsoft.Office.Interop.Outlook;
...
void SetupCommandBar(Outlook.Application application)
{
Office.CommandBar menu =
application.ActiveExplorer().CommandBars.ActiveMenuBar;
Office.CommandBarButton button = menu.Controls.Add(
Office.MsoControlType.msoControlButton,
Type.Missing, Type.Missing, Type.Missing, true)
as Office.CommandBarButton;
button.Caption = "Click Me!";
button.Click +=
new Office._CommandBarButtonEvents_ClickEventHandler(button_Click);
}void button_Click(Microsoft.Office.Core.CommandBarButton Ctrl,
ref bool CancelDefault)
{
System.Windows.Forms.MessageBox.Show("Clicked Button!");
}
The button stops working due to the mystical powers of the .Net garbage collector. If we look closely we notice that the button object is locally scoped in the SetupCommandBar function, thus once we execute that function the button object is free to be cleaned up. However, until the button object is actually destroyed by the garbage collector the button click event will fire and the button will work. Due to the non-deterministic nature of the garbage collector we have no idea how long the button will work. In my simple testing it seemed to work for a little while but if you want to speed up the process add a call go GC.Collect in the button_Click callback.
The easiest fix for this problem is to change the scope of the button object to be a member variable of enclosing class. By doing this we ensure that the button object stays alive and works until we are ready for it to stop working.
I've been noticing some feedback lately where a number of developers were having problems working with the controls on their form region. Usually, these problems manifested as Outlook's object model returning null values back when trying to access the Controls collection of the UserForm object in the Microsoft Forms 2.0 library (which was accessed from the FormRegion.Form property).
This can be especially frustrating, because it looks like you've done everything right, and Outlook is just giving you back something that is totally wrong. Turns out, that isn't quite the case.
If you've added a reference to the 'Microsoft Forms 2.0' type library, you might have added the wrong reference to your project. On some computers, you'll find two different listings for the forms type library in the Add Reference dialog:
Depending on which reference you select, you'll either get a reference properly associated with the Primary Interop Assembly provided by Office, or you'll get a reference with a Visual Studio generated interop assembly. Unfortuatnely, the VS generated interop assembly incorrectly maps some elements of the type library to elements in the interop assembly. This ultimately means that when you are using this reference, you'll end up calling into a different property or method than your code appears to be calling, which causes various strange exceptions and errors.
You can easily determine which reference you are using by selecting the reference and looking at the properties of the reference. If you've added the self-generated IA reference, the properties will look like this:
Notice that the reference has "Copy Local" set to True, and that the Path is not pointing at the Global Assembly Cache (GAC) but rather to the location of my solution. This indicates that I'm using a self-generated interop assembly, and that I may be running into issues.
If you've added the correct reference to the PIA, then you'll see properties that look like this instead:
This time around, you'll see the Path is pointing into the GAC, and the "Copy Local" property is False. This indicates the PIA is being used, and everything should work normally.
If you find your project is using the incorrect reference, you should remove the reference and add a new reference. Unforutnately, there is no way to determine which reference is the "right" reference from the Add References dialog. You'll simply need to use trial and error and double check after adding the resource to make sure you've picked the right one.
The Take-away: Make sure you are using the right interop assembly when working with custom forms or form regions from your managed code solution. Using the Visual Studio generated interop assembly can cause mysterious errors in your solution that you may not catch right away.
We've just rolled out the new Outlook team blog, which is the "one-stop-shop for tips, tricks, and rants directly from the Outlook product team."
Don't worry though, my blog won't be going away. I'll continue to blog about Outlook programmability, custom forms, and other developer-centric parts of Outlook.
If you've been watching other blogs, or the recently published KB articles, you probably have seen this already, but I thought I'd point it out for the rest of you. Last week we released an update for Outlook that fixes some issues that we were not able to fix for Outlook 2007 RTM. Included in this fix are a couple of performance tweaks which help out some of the performance problems users were reporting when running with a large PST or OST file and Outlook 2007.
More details of the update are avaialble in the associated KB article: http://support.microsoft.com/kb/933493.
Direct link to the patch download here.
This won't fix everyone's performance problem, but it does make several common causes for performance issues in Outlook 2007 less of an issue.
Warning: If you're using Outlook 2007 with Business Contact Manager, you should read this article first. There is a follow up patch you need to install to maintain the full functionality of Business Contact Manager.
OK, so this might be a bit off-topic from my regular blog posts, but since I am working on the Internet mail experience for the next release of Outlook, I wanted to hear from some of you about your experiences using our Internet mail account types (POP and IMAP).
In Outlook 2007, we did some improvements to make these account types work better. For example, in IMAP we now allow you to configure your Sent Items folder to actually live on the IMAP server instead of in a local PST file.
Back to the questions however:
- How could we improve your experience using Outlook for Internet mail?
- What do other clients do that you'd like to see Outlook do?
- Do you use Outlook on more than one computer with your Internet accounts?
Of course, if you have other suggestions or comments you'd like to add about our Internet mail support, then you can add those to the comments as well. I'll make sure to read them all and reply as approriate.
If you're running Windows Vista, or Outlook 2007 on either Vista or Windows XP, you're probably wondering just how long you have to wait until you can use the preview capabilities of your new operation system or Outlook client to view PDF documents.
While I still haven't seen an official solution to the problem from Adobe or any of the other typical PDF reader component companies, I have found a few answers online. There are a couple of different downloads that will solve your problems, depending on the PDF reader you favor.
- Foxit: Tim Heuer has partnered with Foxit software to create Foxit PDF Preview Handler, which works with Foxit Reader.
- Acrobat: I've created a similar freeware component that works with Adobe Acrobat Reader 7.x or later. If you favor using Adobe Acrobat, take a look at my PDF Preview Handler.
If you know of another solution to the problem, add a comment here so other users can find a solution for their PDF previewing problems.
Randy Byrne and I have just received our first copies of our book, Programming Applications for Microsoft Office Outlook 2007. This means that it should be showing up in your local book retailer or super-mega-online-bookstore very soon (like over on Amazon). While I'm probably a little partial since I'm a co-author of the book, but I think this is really a great guide for developing add-ins and application solutions using Outlook 2007. The book covers everything from writing your first add-in to advanced topics like using the PropertyAcessor and creating solutions with form regions. Randy and I both have put a lot of effort into this book to make it what should become the standard reference for any Outlook developer.
Depending on when you see this, you might notice that my name isn't listed on the online book retailers. Don't worry though, it's there on the real copies of the book :).
If you pick up a copy, let me know what you think about the book. You can also rate the book over on the MS Press website, if you want to provide feedback in a more managed way.
Last week we uploaded revised versions of our sample code for Outlook 2007 add-ins. The biggest change to these samples is that they are now provided as both a shared add-in project and VSTO 2005 SE project, so that you can see how add-in development would work using either technology.
These samples should give you a good basis for working with form regions, custom task panes, rules, the Table and PropertyAccessor objects, Ribbon extensibility and context menu customization.
You can download the latest samples from the following links: