Controlling Word as a Server Application

[Joseph Geretz]

I'm writing a document viewer in VB6. The basic strategy is to maintain
documents in their native application (e.g. Word) but to have the document
embedded into our own application. Using the Win API I can launch Word and
have it open the specified document at launch time, I then use the WinAPI to
embed the Word application into my own application area. When transitioning
to a new document I simply dump the existing instance of Word and open the
next document with a new instance of Word.

Optimization time...

Instead of constantly reopening new instances of Word, I'd like to reuse the
same instance of Word for subsequent documents. However, I'm having trouble
getting Word to close the current document. (Remember, I'm not using COM
here, I just have a handle to the Word application window.) I suppose the
brute force approach would be to use SendKeys to send the appropriate
keystrokes. But how to open a document? Alt-F O will trigger a dialog box
for the user to select a file, but that's not what I want. The user has
already selected a file via our own application UI. Now I just to direct a
running instance of Word to open that file. Any ideas?

Thanks for your help!

- Joe Geretz -

 

[Jonathan West]

Hi Joe,

Why on earth are you not using COM/OLE Automation for this? It is a classic
application for it.

The following article gives you the basics of controlling Word

Control Word from Excel
http://www.mvps.org/word/FAQs/InterDev/ControlWordFromXL.htm

Don't worry that it says "from Excel", the same principles & code apply just
as well from VB6.

--
Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com

 

[Joseph Geretz]

Hi Jonathan,

I guess your suggestion is the obvious one. However, a few factors
determined our choice of WinAPI, rather than COM Automation for this.

1. Each application has it's own automation model. This means that we'll
need to provide x number of code blocks for x number of applications. The
WinAPI is generalized, and works for any application as long as I can locate
its window (so far so good). WinAPI is the great equalizer. By using the
WinAPI to find the associated registered application, I can manage a huge
number of documents in applications which I never even thought about at the
time the code was written! I've been amazed myself at the types of documents
which I can maintain embedded in our application.

2. Not all applications expose an automation interface.

3. WinAPI has remained relatively constant across 2000 / XP / 2003. Who can
guarantee me that the Office application automation models will remain as
constant across Office 2000 / XP / 2003. Have they? Will they?

So ultimately, Win32 is the lowest common denominator, which is why we're
currently using it.

- Joe Geretz -

 

[Lars-Eric Gisslén]

Joseph,

Win API are calls to the kernel of Windows, not running/controlling another
Windows Application. Using Win API to communicate with another applications
is mostly just to that applications GUI via the event processing. That is
far from calling another applications API. It's up to the developers of the
Application if they wan't to expose functionality of the application or not.
If they provide an API the developers decides if that interface will be via
COM or exported functions. That has nothing to do with Win API calls. If an
application exports it's API only via COM you have no alternatives to
control that applications functionality than COM.

Of course you can get handles to different Windows and query each Window for
it's child windows/controls and send messages to them (as long as they are
instanciated), but that is far from calling internal functionality in the
app itself, only the GUI controls. Trying to run another COM application via
Win API it is so limited so I would not even think about doing that.

If you want to control another application via COM and is worried about the
interface, and you really like low level programming, you could do that
anyway. You can use Windows COM API's to get the applications automation
interface, or read it's type library, and get the interface that way and use
the applications IDispatch interface (or VTable if it supports dual
interfaces) to control it. But that would require a tool like C or
equavalent.

Regards,
Lars-Eric

 

[Jonathan West]

Hi Jonathan,

I guess your suggestion is the obvious one. However, a few factors
determined our choice of WinAPI, rather than COM Automation for this.

1. Each application has it's own automation model. This means that we'll
need to provide x number of code blocks for x number of applications. The
WinAPI is generalized, and works for any application as long as I can locate
its window (so far so good). WinAPI is the great equalizer. By using the
WinAPI to find the associated registered application, I can manage a huge
number of documents in applications which I never even thought about at the
time the code was written! I've been amazed myself at the types of documents
which I can maintain embedded in our application.

In terms of automating applications, and opening files using those
applications, you aren't much using the *Windows* API as the APIs of the
individual applications. In most cases, this means COM. If all you are doing
is opening a file using something like ShellExecute, then you must accept
severely restricted functionality in what can b done after.

2. Not all applications expose an automation interface.

In which case, there is little that you can do to automate them.

3. WinAPI has remained relatively constant across 2000 / XP / 2003. Who can
guarantee me that the Office application automation models will remain as
constant across Office 2000 / XP / 2003. Have they? Will they?

They have remained pretty constant. However, if you want to support multiple
versions of Office then you have to test under multiple versions of Office.

So ultimately, Win32 is the lowest common denominator, which is why we're
currently using it.

In which case you have to accept the restrictions on what you can do.

 

[Chad Knudson]

You can use Word as a doc object server but be warned that there are
limitations in the functionality you'll get. We hosted Word as a doc object
server and found that some of the things we really wanted to do such as
print preview were unavailable.

 

[Joseph Geretz]

Hi Jonathan,

(and this relates to Chad's comment as well.)

In terms of automating applications, and opening files using those
applications, you aren't much using the *Windows* API as the APIs of the
individual applications. In most cases, this means COM. If all you are doing
is opening a file using something like ShellExecute, then you must accept
severely restricted functionality in what can b done after.

We're not so much automating these applications as we are embedding them in
our own app workspace. So really, all the automation necessary, is spinning
up the application and opening the document, which can be done via
ShellExecute. After this happens, the application window is located and
embedded into our own application workspace. After this, the user is on his
own so to speak, free to do whatever they want within the embedded app. Our
application doesn't pick up processing until the user is done with the
embedded app.

In which case, there is little that you can do to automate them.

Right. But the comment above addresses this point as well. We're not doing
much automation. Mainly application launching and embedding.

They have remained pretty constant.

Pretty constant? Is that like IE is pretty much the same as Netscape?

However, if you want to support multiple
versions of Office then you have to test under multiple versions of Office.

Naturally.


In which case you have to accept the restrictions on what you can do.

Again, naturally. (Which is always the case, no matter what approach you
take.)

Ultimately, the only desired function which is missing is the ability to
'reuse' an existing application for successive documents. But since we've
begun to use Word and Excel viewer to initially bring up the document this
has become much less of an issue since these applications launch much
quicker than do their full-blown office counterparts. Performance is
excellent and we're remaining with API for now, to launch applications and
open documents.

- Joe Geretz -

 

[Jonathan West]

Pretty constant? Is that like IE is pretty much the same as Netscape?

Constant enough that it is practicable to write add-ins which work with all
3 versions of Word.