COM Addin (O2K)

Topic

New Reply

A couple of years ago, I attended the ODDC and COM Addin’s were the hot topic.(Along with that Access workflow designer thing that didn’t seem to go anywhere.) COM Addin’s sounded like a pain in the you know what. They were very difficult to debug and tricky to get working. Have they improved over the last couple of years? I haven’t had the need to use them. I can’t think of any time where a COM Addin would have been better than a Application Specific Addin. I’ve never had the need to have similar functionality across Word, Excel, and Powerpoint… Maybe the Office related projects that I work on aren’t a big enough to warrant COM Addins. What are your experiences with COM Addin’s?

Reply | Quote

Replies

What a timely question

I have written an Add-In that will list all the declared VBA variables in a VBA project. Currently I have to maintain 5 separate version (W97, XL97, W2K, XL2K and A2K), all in the native file format of the application.

I am, as we speak, looking at the MSDN site to see what it will take to convert this to a COM Add-In, so I only have to maintain 1 version, possible 2 (Office 97 and O2K).

Hopefully , it won’t be too much.

Reply | Quote

Only Office 2000 and Office XP support COM Add-Ins.

Reply | Quote

We use a COM Add-in for Outlook. The logistics of distributing VBA solutions for Outlook are otherwise prohibitive. Maintenance has not been a big issue: I’m just leaving some minor things broken until more people complain. But seriously, debugging was more arduous than usual, and it left dozens of apparently useless entries in my registry from all the reinstalls. I haven’t cleaned them out yet, since I don’t know which ones matter… from the end-user perspective, the Office 2000 version seems to work fine with Outlook 2002. Unfortunately, I wasn’t able to make it work with WordMail…

Afterthought: This was done in Office 2000 Developer, not VB. I have no idea how it would differ with VB.

Reply | Quote

COM Add-Ins have, from my view, the following advantages over using a VB created ActiveX DLL:

1. With a COM Add-In, you can more easily tweak the code to work in more than one app, say, Excel and Word.

2. A COM Add-In protects ALL the code. Using a VB created DLL, the only code that is protected is the code included in the DLL. Unless, you code the VB DLL to use, say, Excel via Automation, the Excel dependent code is not protected as securely as the code in the DLL.

Reply | Quote