How to Create an Outlook Plugin using Delphi?

Question

Hi,

I'm working on a database project and I need to create Outlook 2007 plugin that saves the current previewed message into my database.

Can someone give me a step-by-step guide on how to create an Outlook plugin in Delphi, and how to deploy it?

Thanks

Answer 1

I only know of commercial solutions, are you looking for 'free' solutions?

Answer 2

Add-in Express looks good.

Answer 3

mmmm...

well, thanks guys anyway but I'm looking to learn how to do it without using any third party components, I don't think that every company uses a third party components, it could be done by code, or I'm wrong?

Answer 4

I created a Plugin once for use in Excel (Creating my own User Defined Functions) with Delphi. What you need is an Addin that implements the _IDTExtensibility2 interface.

Now I don't know the exact steps, but searching for _IDTExtensibility2 will help you a lot.

Check this article for a nice how to. The OnConnection procedure of the _IDTExtensibility2 interface gives you the entry to the Outlook application.

Answer 5

I've built an outlook add-in using Delphi (integrating a room reservation system into the appointment form).

Some advice:

• Buy and use add-in express. It will save you a lot of time, and it allows you to build COM add-ins that don't require any third-party components at installation time. We tried building our own component first, and although we managed to put buttons on forms that did something, the amount of time spent was disproportionate to the result.
• Use the add-in express support service when in doubt. They know their stuff.
• The COM interface for outlook (found in the delphi/ocx/servers/ folder) is your friend. Add-In Express merely provides a (much) more convenient wrapper around this functionality.

Things to avoid:

• Straight MAPI calls. It can be done, and in fact I had to resort to it for modifying message streams in transit, but it's a real PITA to work with and very poorly documented.
• One-off forms. We wasted a lot of time trying to get one-off forms to work. Only use published forms. You can publish a form to the local folder from code, so in practice this is not a big deal.
• Pretending like COM in Delphi is anything like normal VCL programming. My advice if you don't have COM experience is to read any and all documentation you can get your hands on. Some hard-learned lessons were to always set variables to nil before the end of a function so objects could get freed correctly by outlook, and to always request the appropriate interface from an object instead of trying to cast it.

Answer 6

To bad the job has to be done in Delphi. With .NET and VSTO creating Outlook addins is far less painfull compared to the bad old days. I have made Office addins in COM (that was NOT funny at all) and in the previous version of VSTO, but VSTO 3 is very good news for the office developer.

Answer 7

If you just want to learn and understand how to do it, just google for Delphi Outlook addin (I'm pretty sure "addin" should give you much more relevant results than "plugin" in this context) and you should come up with a number of slightly dated but still formally correct sample addins, e.g. the Babelfish addin from Dmitry Streblechenko (which is no longer useful because the web service it relies on no longer exists but still shows the basics) or the sample addin from Paul Qualls (which is unfortunately no longer available from the original site). There's also a mail whitelister addin available with complete source, but I haven't looked at that yet.

However, sooner or later you will want to start using a proven framework like ADX, especially if your addin is going to be used outside your company. We develop a shareware addin in Delphi and about 75% of the code in the addin is just there to provide support for the various versions of Outlook (especially Outlook XP) and different setups (most notably the option to use Word for message editing has been a major table-biter for us).

Another factor is having to constantly work around the stupid OOM security model. You're pretty much busted without Redemption or Outlook Security Manager there. Redemption especially could not be recommended highly enough, not only for avoiding the security prompts but also for simplifying a plethora of tedious routine tasks with a solid, easy-to-use framework of its own.

[Addition:] We did start out with our own home-grown framework and all was well with it until the number of users and with them the number of different configurations to support exploded. We switched to ADX about a year ago and never looked back. Using Redemption was a no-brainer right from the beginning though - it was either that or spend months learning Extended MAPI before we even got started (you do still tend to pick that up much easier as you go along once Redemption has guided you over the first few hurdles).

BTW: Another indispensable tool for any self-respecting addin developer (regardless of programming language used) is OutlookSpy. This will really allow you to see (and manipulate) what goes on inside Outlook (and to some extent Exchange) as it happens and give you a much better understanding of what your addin will have to do in order to achieve the effect you want.