If you’ve ever tried to write Add-ins for Microsoft Office, you know that it can be a pretty intimidating task. Sure the splash screens might look the same, but underneath, Office is a whole collection of different versions of different products, and this becomes really apparent when you look under the hood at the various API interfaces.
There have been several attempts by Microsoft to add consistency to the way that solutions are developed on the office platform (with Visual Studio Tools for Office being the latest, and probably best entry), but when it comes down to it, to deploy anything really useful, you have to resort to learning 4 different versions of 5 different object models.
Or do you? As you fumble your way through looking for sample code to make your life easier, there’s a high probability that you’ll end up on the Add-in Express site. When I first came across these guys, I checked out their claim that their product, Add-in Express, allows you to “Make office programming fast, comfortable and trouble-free”. I snorted.
“C’mon. Nothing can do that…” I then hit the back button and clicked some link to Experts-Exchange and auto-scrolled all the way to the bottom. You can’t believe everything you read on the Internet, right?
Much later, Dean found another positive review for the Add-In Express guys on StackOverflow, and as we were about to begin a new iteration of our Office add-ins, he suggested that we should give them a try. I spoke to Andrei about getting a demonstration license, and installed the toolkit to build the next version of our Outlook Add-in. Within 2 days, I was converted. Add-in Express is a remarkable piece of software.
Using Add-in Express is weird, but then, writing Office Add-ins is weird, so I guess that makes sense. Rather than have a traditional WYSIWYG designer, there is a canvas that allows you to add big icon-like controls, and then you set those controls’ properties through various properties dialogs. You handle events, write module level code, add references and any control you like.
When you’ve configured these things to your liking, you simply register the add-in from the build menu, and then start your target office application. Your add-in is configured for you. If you want to debug it, you just attach to the process, and step through your code. It has dramatically improved the reliability, speed and most importantly development time for our MS Office integration.
Add-in Express also adds a setup project to your solution, and builds you the MSI as you go. When you want to deploy your add-In, you simply run the MSI on the target machine.
Support from the Add-in Express guys via their forum was prompt and very helpful. It became patently clear to me that these guys have already fallen into, and successfully gotten out of, all of the traps, potholes and tricks that are awaiting you in the mysterious world of Office Development. If you are planning on doing some serious Office Integration, this kind of knowledge is invaluable. Highly recommended.
One of the things that I had to do in Outlook this week was to determine if an outlook MailItem is part of a conversation.
After much googlework, I discovered two properties on the Outlook MailItem – ConversationIndex and ConversationTopic.
To determine if an Outlook Item is part of a Conversation, you need to look at the first 22 bytes of the hex string reported for ConversationIndex. If they are the same, then the message is part of the same conversation.
That’s all well and good, but note that this property is somewhat unreliable. For starters, in versions of outlook prior to 2003, it returned binary data, instead of a hex string (but if you’re working with versions of Outlook prior to 2003, you probably have other problems…) The other reason this property is unreliable is because it is set by the client – Outlook appends a 5 byte timestamp to the ConversationIndex when you reply. Which is cool, as long as you reply through Outlook.
But – our Infovark mail server is hosted by Google, and I occasionally use the gmail web client to reply to mail, instead of Outlook. For these conversations, when the replies were eventually retrieved into Outlook via IMAP, they ended up with unique conversationindexes, and so I couldn’t identfy them as being part of the same conversation.
In these cases, that’s where the ConversationTopic Property can help give you a clue. The ConversationTopic is the normalized subject of the message, that is, the subject without all the prefix strings (“Re:Re:” etc.) By comparing ConversationTopics, you can usually piece together the conversation, even if the ConversationIndex is not correct.
Sometimes COM Objects return a HRESULT that is outside of the bounds of a C# integer.
Unfortunately, the only way to correctly handle a COM Exception in .NET is to use the ComException Class. But if the HRESULT isn’t an Int, and the ErrorCode Property on the ComException class is an Int, how are you supposed to ever be able to catch that specific HRESULT?
Fear not! Here’s how to handle a COM ErrorCode that can’t be converted to an Int (in this example, it’s unsigned)
The magic happens in the ‘unchecked’ statement – which tells the compiler not to perform the overflow-checking context for integral-type arithmetic operations and conversions.
More on the Unchecked Operator over on MSDN.
For what seems like the thirteen-thousandth time, I just accidentally pushed the F1 key while I was writing some code. It’s pretty close to the escape key. I didn’t mean to push it. I guess I just have fat fingers.
I really, really hate pressing F1 in Visual Studio. Usually, it takes about a minute to display Microsoft’s help documentation thingy, which is impossible to navigate, frequently wrong and and generally not very helpful. This afternoon, the document explorer decided it had to go and update itself, which took about five minutes before it could take it’s usual minute to load the non-relevant, non-help, that I didn’t even want in the first place!
During this time, Visual Studio was COMPLETELY Unusable. The help dialog blocks the main visual studio thread – and all attempts to get back to work were greeted with a friendly, informative “This may take several minutes” dialog.
Time Passes…
Time Passes…
Time Passes…
Arggh! Gord Mad!… And it turns out it’s not just me. This annoys other folks, too!
Right. That’s it Visual Studio. You’ve made me go through this song and dance for THE LAST TIME!
For starters, where do we all go for help? To Google, that’s where. So, I added an external tool using the Tools>External Tools Method:
I set up my command to point to Firefox, and passed as the arguments:
http://www.google.com/search?site=&hl=en&q=$(CurText)+c%23&
(The +c%23& part of the command appends “C#” to whatever is highlighted in the IDE. If you’re not using C#, you could leave it out, or substitute it with whatever else you usually search for)
Then, I flipped over to the Keyboard bindings screen (Tools > Options > Keyboard:)
And I re-mapped the F1 key to my new ExternalCommand1.
There! Now, whenever I press F1, Visual Studio opens a new tab on my web browser, and searches Google for whatever I have highlighted in the IDE.
Purposefully punishing developers with a minute or two wait everytime they press a certain key is just plain unforgivable. They get really distracted trying to work around the “functionality”, and then further distracted writing ranty blog posts about it…
The BCLTeam just released a really neat looking tool that makes it much easier for us Managed Code types to interoperate with the dirty bowels of windows (also known as the Win32 API : )
Called the P/Invoke Generator, it inspects any Win32 API call, and then generates the interop code that you need to be able to call it in either C# or VB.Net. It also lets you generate P/Invoke calls from any other native library.
Nice one! You can download the tool for zero dollars over on CodePlex