COM Add-in vs. Automation vs. Word Add-ins vs...

COM Add-in vs. Automation vs. Word Add-ins vs...

Post by Dr. Z-Ope » Tue, 29 Feb 2000 04:00:00



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

======================

 
 
 

COM Add-in vs. Automation vs. Word Add-ins vs...

Post by Jonathan Wes » Tue, 29 Feb 2000 04:00:00


Hi Sean,

If you are doing an add-in, I think the old CAPI method will still work, but
there is little in MSDN on it. For what there is, see Q195483, Q131723 and
Q183165 in the KB.

However, it seems that, if a straightforward template loaded as an add-in
isn't good enough for you, then the Way Of The Future as described by
Microsoft is to create a COM add-in (essentially an ActiveX DLL.) You can
use VB6 or Office Developer edition for this. I presume you can also use
C++. I haven't yet experimented, with them. I believe that the communication
between Word and the add-in uses OLE automation.

As for advantages and disadvantages, these will depend rather on your
purpose and your own prior knowledge, and as I know little about either, I
can't really advise :-)

Sorry if this sounds a bit vague, but you are pushing on the boundaries of
my knowledge. I'm speaking more of things I have read than things I have
tried for myself.

Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com
Word FAQs at http://www.multilinker.com/wordfaq
Please post any follow-up in the newsgroup. I do not reply to Word questions
by email


>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

>======================


 
 
 

COM Add-in vs. Automation vs. Word Add-ins vs...

Post by Dr. Z-Ope » Tue, 29 Feb 2000 04:00:00



Quote:> Hi Sean,

> If you are doing an add-in, I think the old CAPI method will still work,
but
> there is little in MSDN on it. For what there is, see Q195483, Q131723 and
> Q183165 in the KB.

Hi Jonathan,

Thanks for the response and info.

Yes, one can still use the CAPI, however, it has not been revised since 1995
and therefore is grossly stale. Also, it's not guaranteed to be "supported"
forever.

Quote:> However, it seems that, if a straightforward template loaded as an add-in
> isn't good enough for you, then the Way Of The Future as described by
> Microsoft is to create a COM add-in (essentially an ActiveX DLL.)

Right.

Quote:> You can
> use VB6 or Office Developer edition for this. I presume you can also use
> C++. I haven't yet experimented, with them. I believe that the
communication
> between Word and the add-in uses OLE automation.

I am using C++, as I did in the old project. The current application is
roughly
a million lines of code, so it's not trivial. I expect the new project will
be not
quite as massive in terms of SLOC, but certainly not a Template based
application.

I still find "Automation" a bit of a nebulous, or ambiguous term. What I
want
to accomplish is for my DLL to load when Word starts, in the old WLL
fashion.
The Automation examples that I've seen are such that the Client starts as an
EXE and *it* calls the Server, in this case Word, and "automates" it.

I guess it's all semantics... much of a muchness. That is, a "COM Add-in"
makes use of the same machinery as so-called "Automation", ultimately.
There are at least some details that differ in terms of startup details.

Quote:> As for advantages and disadvantages, these will depend rather on your
> purpose and your own prior knowledge, and as I know little about either, I
> can't really advise :-)

> Sorry if this sounds a bit vague, but you are pushing on the boundaries of
> my knowledge. I'm speaking more of things I have read than things I have
> tried for myself.

I do appreciate the rejoinder Jonathan - thanks!

--
Sean

--
======================
         Sean C. Murphy
    Sr. Software Engineer
      Document.Com, Inc.
       617.542.7200 X232

======================

> Regards
> Jonathan West - Word MVP
> MultiLinker - Automated generation of hyperlinks in Word
> Conversion to PDF & HTML
> http://www.multilinker.com
> Word FAQs at http://www.multilinker.com/wordfaq
> Please post any follow-up in the newsgroup. I do not reply to Word
questions
> by email


> >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

> >======================

 
 
 

COM Add-in vs. Automation vs. Word Add-ins vs...

Post by TomV » Wed, 05 Apr 2000 04:00:00


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

> ======================

 
 
 

COM Add-in vs. Automation vs. Word Add-ins vs...

Post by Niki Estne » Thu, 06 Apr 2000 04:00:00


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

> > ======================