|
From
TNPC issue #3.20...
Corporate Corner - Customizing Word 2000 Using the Windows API and a COM Add-in
by Lee Hudspeth
September 28, 2000
(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
Lee Hudspeth is Director of Development at PRIME Consulting
Group, Inc., and can be reached at:
mailto:code@PRIMEConsulting.com
Copyright © 2000, PRIME Consulting Group, Inc. and Dan Butler.
All Rights Reserved.
The Naked PC is a trademark of PRIME Consulting Group, Inc.
ISSN: 1522-4422
You may reprint an article from TNPC as long as you show the
entire article and include the authors byline, excerpt and
subscription information as shown:
Corporate Corner - Customizing Word 2000 Using the Windows API and a COM Add-in
by Lee Hudspeth
(This article originally appeared in The Naked PC
newsletter #3.20, subscribe at http://www.TheNakedPC.com)
|
Return to Top