Using MSWORD9.OLB to create Word Documents

[Srini]

hi all

I am trying to create a word document , using Microsoft Word 9.0 Object
Library.(MSWORD9.olb). I made a setup file of VB application with follwing
code, using deployment and setup wizard of visual studio.

Dim objApp As Word.Application
Set objApp = New Word.Application
'Start a new Normal template document
Documents.Add
'Format document heading

The code works fine on a system which got Microsoft Word 2000 installed,
whereas when i run this code on a clean system without Microsoft Office /
Word 2000 it gives out error message saying cannot create object of Activex
Component. When i do a research on this problem, i came across this info
saying
"The Package and Deployment Wizard does not recognize the *.olb file
extension as a type library and incorrectly assumes it to be a binary
executable"
from here
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:
80/support/kb/articles/q249/8/43.asp&NoWebContent=1

I need to create a word document on a system where MS - Office will not be
there. How do i do this ? Any help is appreciated

Thanks
Srinivas

 

[pre]

Maybe there´s some help in this KB:
292744 - BUG Automation Client Receives Error or Crashes Calling Word's Find
Object.mht

At least there are appropriate references.

 

[Jezebel]

You're not free to distribute MSWord9.olb. The user must have a licence for
it; which they'll have only if Word is installed anyway.

 

[JGM]

Hi Jezebel,

Just curious...

Not that I would want to develop an application needing a software not
present on a target computer (!?! WUWT?).

But just for the sake of the discussion..

You're not free to distribute MSWord9.olb. The user must have a licence for
it; which they'll have only if Word is installed anyway.

Are you saying, in answer to Srinivas' question, that, hypothetically
speaking, by just having that library present and registered on a computer,
one could create Word document on that computer?

Puzzled...
TIA

 

[Jezebel]

That file is the key file that does the work of creating Word documents, and
if you add it as a reference to a VB or VBA project you can create and edit
documents programmatically (do everything, in fact, that someone using Word
can do). However, that file alone is unlikely to be enough: you also need
any other files (other olb, dll, etc) that MSWord.olb is dependent on. As
far as I know, you can't simply copy and register olb's to get around the
licensing requirements.

 

[Thomas Winter]

Uh, that's not true. OLB files are just DLL's that have a type library as a
resouce. They just define the object model if you will, but they don't
implement it. You have to have Word (WINWORD.exe, etc.) on the system in
order to actually DO anything.

Tom

 

[Jezebel]

Isn't that what my post says? Or didn't you read to the end? And DLLs do a
lot more than define the object model!

You certainly need the files that are part of Word (as I said in the
original post); but ironically, if you are calling Word from VB, the one
file you don't need is Winword.exe. (that's just a command-line access point
to files that actually do the work; but if you're calling from VB you
obviously don't need the command line.)

 

[Lars-Eric Gisslén]

Jezebel,

Sorry, but I don't believe you. This is the command line to start Word as an
Automation Server (and that's what you actually do when you start it from
VB):

C:\Program\MICROS~1\Office\WINWORD.EXE /Automation

An EXE file that is 8 mb+ in size just acting like a commandline interpreter
would be a real overkill. The EXE is also the host for all DLL's that
belongs to Word as they resides in the EXE's address space.

 

[Byron]

Isn't that what my post says? Or didn't you read to the end? And DLLs do a
lot more than define the object model!

You certainly need the files that are part of Word (as I said in the
original post); but ironically, if you are calling Word from VB, the one
file you don't need is Winword.exe. (that's just a command-line access point
to files that actually do the work; but if you're calling from VB you
obviously don't need the command line.)

I thought that creating the "New" instance of a Word.Application
object actually gives you a new instance of Word. If Word is already
running than you can use a "GetObject" call. Either way, when you
look in task manager, Winword.exe is indeed running and can be viewed
in the ROT. Kill it through task manager and your application will
suffer the consequences.

 

[Jezebel]

If you start Word like that, yes of course. But if you use

x = createobject("Word.Application")
or
Dim x as Word.Application

then WinWord.exe doesn't come into it unless you instantiate Word's GUI
also.

 

[Jonathan West]

If you start Word like that, yes of course. But if you use

x = createobject("Word.Application")
or
Dim x as Word.Application

then WinWord.exe doesn't come into it unless you instantiate Word's GUI
also.

Sorry, that's not correct. Winword.exe is started as a process, and duly
appears in the list of processes in Task Manager in Win 2K or later.

It doesn't appear in the list of tasks, because the application isn't yet
visible. But be very sure, winword.exe is started when you run
CreateObject("Word.Application")

An instance of winword is started in all of these circumstances

1. late-binding
Dim x As Object
Set x = CreateObject("Word.Application")

2. Early-binding
Dim x As Word.Application
Set x = New Word.Application.

3. Auto-instantiation
Where a reference to Word has been set in Tools References, the first use of
any object within the Word object model.


I've just checked this on my own machine. I recommend you do the same.

 

[Lars-Eric Gisslén]

Jezebel,

I must say you are wrong. I didn't mean you should start Word like I showed
as it would be totally meaningless. I just showed how Word is started when
you start it as an Automation Server. You can verify that by looking into
the Registry.

1. Find HKEY_CLASSES_ROOT\Word.Application\CLSID

That key refrences a Registry entry for the application like (Word 2000):
{000209FF-0000-0000-C000-000000000046}

2 Then locate
HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046}\LocalServer32

There you will find how Word is started as Automation Server
(Word.Application), actually like this:
C:\Program\MICROS~1\Office\WINWORD.EXE /Automation
(On my computer)

This is a typical way of starting an Automation Server. I have written
applications that acts as both stand alone applications and also as
Automation Servers. In the start routine I check if the parameter to the app
is '/Automation'. (If it should be /Automation or something else is up to
the programmers) If it is, I don't display the application window and start
the Com event processing. Otherwise I display the application Window and
start the normal event dispatcher.