A few months ago I wrote about an approach to improving .NET cold startup performance. Here’s a little more information that I’ve learned since then.
I spent a few days implementing a component that adds some custom properties to Office 2007 files. Using the System.IO.Packaging namespace from .NET 3.0, and looking at some sample code in some Visual Studio snippets, things went pretty smoothly. Just when I thought I was done, though, I tried opening a manipulated .docx file in Word and got the message “The file is corrupt and cannot be opened.”
Sometimes you want the window handle of the host application when you’re writing an Office add-in. Excel includes that as a property of the Application object in newer versions of the object model, but Word and PowerPoint don’t. I seem to remember some sample code from Microsoft that suggests using FindWindow to get the handle, but that always seems problematic:
- You can search by class name (e.g. “OpusApp” for Word), but what if you somehow have multiple Word processes running? Which window do you get?
- You can search by window text, but it can be really hard to figure out what the window text is.
- You can set the Caption property on the Application object to some magic text and search for a window with the magic text, but Word throws all kinds of other stuff into the caption so this generally doesn’t work reliably.
Instead, if you’re using managed code, you can just do this:
IntPtr hwnd = Process.GetCurrentProcess().MainWindowHandle;
Underneath this uses
GetWindowThreadProcessId to find the right window.
I sometimes wonder how often the default paste operation in an application is appropriate. Maybe I’m abnormal (maybe?) but it seems like 73.2% of the time, I want pasted text to match the formatting of where it is going rather than where it came from. I guess the exception is when I’m copying and pasting from within the same document. The result is that I use “Paste Special” a lot.
It’s common for an Office add-in to put some custom menu items or toolbar buttons in the UI of the hosting application. The method to call to do this is CommandBars.Add. It is also typical that you’d like those customizations to appear so long as the add-in gets loaded, but not appear if it doesn’t. If your add-in gets uninstalled, for example, you clearly don’t want left-over customizations littering the application. For this reason, the Add method’s final parameter is a boolean that indicates whether a particular added control should be added temporarily. The documentation describes the parameter like this:
- Optional Object. True to make the new control temporary. Temporary controls are automatically deleted when the container application is closed. The default value is False.
This looks perfect. You can add the customizations at startup, and they’ll be gone at shutdown… except that it doesn’t work in Word.
Last week I went to San Francisco to take a dive off the deep end into the new XML file formats in Microsoft Office 2007. The training was hosted by MindJet, and presented by Doug Mahugh of Microsoft, and Chris Predeek, a consultant who put together the code samples for the hands-on labs.
The documentation around Office 2007 ribbon customization is still a bit sparse. I’ve been trying to add a new entry under the Save As menu in the Office Menu, and after a fair amount of trial and error, I found a way to do that. Continue reading