(Corporate Corner is a new feature in TNPC. It addresses development issues that come up in the course of our various computer consulting projects. -- Ed.)
A corporate client recently approached our firm (PRIME Consulting Group, Inc., publishers of TNPC) with the challenge of putting custom text and graphics on a built-in Word 2000 dialog box. We accomplished this feat by using the Windows API (Application Programming Interface) to draw text and graphics very precisely right on the dialog. One of the client's primary concerns was the cost to recompile the dynamic link library (DLL) we developed should they decide to change the text or graphics in the future. Whether you are concerned with dollar costs when working with "for hire" consultants, or with the hourly cost of your on-staff programmers, you should address ongoing maintenance issues early in a project's development cycle.
Our solution's architecture allows the client to change the dialog's size, caption bar control icon, caption bar text, and the client's special text and graphics (that appears on the body of the dialog) based on custom Registry entries that we created and documented. Using the Registry allows the client to avoid recompiling the DLL to change these properties. Instead they simply update their installer to include the new information, write it to the customer's Registry, our code automatically tracks those instructions from the Registry and dynamically uses the very latest text or graphics. While it would have been simpler to hard-code the values into the DLL, storing the settings in the Registry vastly reduces ongoing maintenance costs.
Once we delivered the solution for Word 2000, the client had an opportunity to see how this new feature benefited their customers, and asked if we could port the feature "down" to Word 97. Whenever you develop for differing versions of a product you have to minimize the issues involved with maintaining two different source code bases. We always strive to use a single source code base. (Interestingly, the client initially opted not to follow our suggestion to develop a single-code-base Word-97- and-2000 solution from the outset. The moral here for the consultant is: give your professional opinion and then respect the client's prerogative to do something else. I can't offer a "moral" here from the client's perspective, because I don't presume to know all the factors that affected the client's initial decision. In the end they got the very best: support for both versions of Word via a single code base.)
The challenge was that Office 97 doesn't support COM add-ins. (See the end of this article for an explanation of what a COM add-in is.) But since a COM add-in is a DLL (technically, an ActiveX DLL) we were able to modify it to export its functionality just like a standard DLL that Word 97 *can* call. So we did. This solution uses the same source code base for the DLL, supports both Word 97 and 2000, reduces the client's development cost, and reduces downstream maintenance and enhancement costs.
If you develop Office add-ins, or are responsible for the hiring of consultants to do the same, bear this in mind: a COM add-in is almost always a better solution than a traditional add-in, say, a Word template (.dot), an Excel add-in (.xla), a PowerPoint add-in (.ppa), and so on. Here's why.
A COM add-in works within a documented, pre-defined infrastructure that allows you to quickly extend your utility's features to any or all Office applications from a single location (the DLL itself). With a COM add-in you don't have to rely on multiple add-in files, there's just one file (the DLL itself). A COM add-in's source code is locked away in binary form in the DLL whereas a traditional Office add-in's VBA project, even if locked, can be quickly broken into using a variety of readily available password crackers. (We're not letting any cats out of the bag here; the existence of these tools has been public knowledge for years.) COM add-ins can be faster than their traditional add-in counterparts, and are much easier to install properly from an installation script (we use Wise Solutions InstallMaster and Wise for Windows Installer).
Earlier we said a COM add-in is *almost* always a better solution. There are cases where a traditional add-in has value, for example, you wouldn't need COM add-ins to handle a set of corporate communication Word templates as long as the templates-- and the code behind them--don't leave the organization. However, in most cases we advocate the use of a "driver" COM add-in along with a traditional add-in as its companion.
For supplemental information regarding Office, VB, and VBA programming resources see: http://www.thenakedpc.com/t/320/tr.cgi?corp
Sidebar: What is a COM Add-in?
A Component Object Model (COM) add-in is a dynamic-link library (DLL) or an ActiveX executable file that is specially registered and can be loaded by any Office 2000 applications. You can create a COM add-in with Visual Basic 5.0, Visual Basic 6.0, or the Developer Edition of Office 2000. For more information on COM add-ins see:
"What Is a COM Add-in?" http://www.thenakedpc.com/t/320/tr.cgi?corp1
"Developing COM Add-Ins for Microsoft Office 2000" http://www.thenakedpc.com/t/320/tr.cgi?corp2
