Tag Archives: msdn

Office Development in .NET is a Mess

First off, a bit of a disclaimer – I admit that I am using Visual Studio 2010 (Beta 2) and Office 2010 (Beta); as such I shouldn’t expect all documentation for them to be complete or everything to being running bug free.

With that said: Begin the rant!

Today I decided to attempt to build an Outlook 2010 add in that would enable me to "block" particular authors on RSS Feeds. The reason I wanted to do this is that I am subscribed to the TechNet, ASP.NET, MSDN and Windows Team combined feeds – these 4 "combined" feeds are a collation of quite a number of blogs by Microsoft. The unfortunate thing is than a number of the blogs are completely irrelevant to me, or in a foreign language. With my Add In I could then block the non-English and irrelevant authors without having to create a-hundred-and-one "rules". So, what went wrong?

First off, there is no "RSS" class.
RSS items are of type PostItem or, more specifically, have a MessageClass or IPM.Post.RSS. So while it is possible to tell that an individual Post item is an RSS item (by doing a string comparison), its impossible to filter or check folders. This isn’t a *big* thing, but it certainly is very annoying.

Don’t use the classes, use the interfaces.
For every VBA class, there is a .NET Interface AND a class; for instance there is an Outlook.PostItem (Interface) and Outlook.PostItemClass (Class). So which to use? Apparently the interface is the one to use, I think. The classes are apparently "COM coclasses that are required for interoperability with the corresponding COM object" – which to me sounds like an Infrastructure class, which is fine if it is private or internal, NOT public. Also, in case you didn’t notice, to add insult to injury there is a class with the word "Class" in its name that is referring to the fact it is a class (and the interface isn’t prefixed with an "I" – but we’ll forgive that).

The documentation is incomplete.
And its not just the 2010 documentation that is incomplete. To use the example above, lets have a look at the PostItem Interface members (Go, click on the link and have a look. I’ll wait right here. Done?). That’s right – they’re empty. But IntelliSense in Visual Studio (and the actual API) tell a different story. Ok, lets assume that (being programmers) they’re lazy. maybe the documentation is in the PostItemClass Class (Again, click on the link…). Hmm…. apparently all of the Properties, Methods and Events do the same thing… which is the same thing as the Class…
Oh, and in the name of fairness, reopen one of those links and check the version of Office the documentation is for. That’s right, 2007.

And, the Pièce de résistance:
Apparently Outlook is now Access in Office 2010 (click on the "Outlook 2010" link) (also, Bing’s cached version, just in case)

Tagged , , , , , ,

Multithreading Analogy

I’ve always been a bit contentious about starting my own blog, “Is it worth it?”, “Will I blog enough?”, “Will people event read it?”, etc. However, after reading this post from the MSDN, I realised that I may as well – even if it is just to repost nuggets of information like this:

This is one of *the* best analogies for how multithreading works and where the performance and stability of issues that poorly written multithreaded applications derive from. Its a bit of a long post, but well worth the read: http://blogs.msdn.com/dsvc/archive/2009/12/10/the-cup-stacker-prince-multi-threading-made-easy.aspx

Tagged , ,