Word exposes some of its functionality through Automation. That's what you
see when you write a VBA-Macro.
Automation is a standardized protocol build upon COM (primarily the
IDispatch interface and friends)
Automation provides:
- Calling an function over thread/process boundaries by supplying the
function name and it's parameters. COM marshals the parameters and return
values, and word (for example) looks up the function-name (or function
number) you called and executes this function - no * crashed because of
dangling function pointers, or broken stack frames.
- Getting event notifications (document saved, new window opened, etc.)
This can be done from almost every windows programming language (VBA,
VBScript, VB, VC++, VJ++...)
An AddIn is usually a in-process COM server (a COM DLL) that is loaded by
Word (for example) in the startup process. The AddIn can then use the normal
automation interface to control word. (In some application AddIn's have
special possibilites to display their own toolbar/menu, but i think with
word this is not the case)
So if you want to do something like "Insert the text >Word Is Dumb< on top
of the document", you will always end up using automation. (Or your
keyboard, of course)
I see three choices:
1. You want to control word from "outside"
You make a seperate executable, and use automation to launch word, open an
empty document and insert some text, and so on.
2. You want to change the behavior of a special document/document template
You make the document, open the VBA macro editor, and start programming.
3. You want to change the behavior of word itself
You make a COM dll (an AddIn) tell word to load it at startup, subscribe to
events, add your own menus, and so on.
You always can do the same things through word's automation interface. But
sometimes you launch word, you are a part of a word document, or word
lauches you.
Niki
> Hi Sean ...
> I'm not a COM expert ... by any stretch of the imagination.
> I decided to use a COM Addin for my Word 2000-dependent project because:
> a. The use of a COM object makes it very compatible with current and
near
> term Windows infrastructure. For example, you have standardization and
> flexibility concerning the installation, licensing, etc.
> b. It has all the advantages (disadvantages) of component-based (and
> COM) software development and delivery.
> c. A _single_ COM Addin can, if properly designed, work with Office
2000
> components Word, Excel, Access, PowerPoint, and Front Page. It make need a
> bit of work to also support Outlook.
> d. There is a VC6 sample that works well.
> HTH
> TomV
> > Hello Folks,
> > I am hoping that some learned person out-there in the COM-aware
> > community can clear-up this... nebulousness, for me.
> > I am about to begin a project which would traditionally be known as
> > a "Word Add-in". I am using VC++ 6 and Word2000.
> > In past such projects we used the old CAPI, and the "Word Add-in"
> > (a.k.a. .wll) would be loaded by Word upon startup by virtue of it's
> > existence in Word's "Startup" folder, and began it's life in the 'C'
> > wdAutoOpen() call. The old application became
> > - Does "Automation" (formerly "OLE Automation") imply that the Client
> > (myClient.dll) launches and commands the Server (in this case Word)?
> > How does Automation differ from a COM Add-in?
> > - Is the "COM Add-in" the right way to go for extending Word's
> > functionality?
> > - What are the implied benefits of using a COM Add-in to implement MS
> > Word extensions over other methods of doing so?
> > Any info concerning the above would be much appreciated indeed!
> > Thanks.
> > --
> > Sean
> > ======================
> > Sean C. Murphy
> > Sr. Software Engineer
> > Document.Com, Inc.
> > 617.542.7200 X232
> > ======================
by