Help: Cross-Version Word Object Library problems (9.0, 10,0, 11.0)

M

Mark Loveless

I'm working in-house on an Access application to which I've recently
added automatic fill-out-the-form functionality. The problem: I'm in
a mixed version environment in regards to Office - some machines are
at Word 9.0 Object Lib, two at Object Lib Word 10.0 and the boss and
myself at Object Lib 11.0. I put the Word 9.0 object library on my
machine (which has Office 2003 installed) and linked to that; that
works fine application-wise - I'm not doing anything close to needing
more Word functionality than that provides - but as best I can tell
whenever I save my version the Reference reverts back to Word Object
11.0, so everytime I send out a new release, which may be a couple of
times a day for misc odds-and-ends fixes, most of the machines in the
office choke, requiring manual intervention on my part to reset the
Reference to whatever they have on their machine.

Is there either

1) Ideal solution I don't expect: A meta-object reference that will
happily use whatever Word object library is present on the current
machine

or

2) a way to force the application to stick to a given Object Library?

I'm going to have the same issue soon with the Outlook lib.

Any help greatly appreciated. TIA



Mark Loveless
Reluctant Access Programmer
(e-mail address removed)
 
J

Jezebel

The basic technique is:

1. Develop your application for the lowest common denominator (ie Word 9, as
you are doing), and

2. Use late binding.

During development add the Word library as a project reference and declare
it using something like

Dim WordApp as Word.Application
Set WordApp = new Word.Application

Then before distribution, remove the Word library reference and change the
declaration to

Dim WordApp as Object
Set WordApp = GetObject("Word.Application")

You can use late binding during development if you wish; but you get no
intellisense help or syntax checking on the Word object.
 
H

Howard Kaikow

If you develop using the earliest version of Word, then you should use
early, not late, binding.
 
J

Jezebel

Howard, perhaps you didn't read the original post. The OP's problem is
precisely that early binding isn't appropriate in this case. Unless you're
suggesting that the OP install the Word 9 library on all machines?

Code developed for Word 9 is upward compatible, so by using late binding the
app will function happily with those users who have later versions.
 
M

Mark Loveless

Thanks. I had been working at it backwards, thinking I would have to
read the registry to get the explicit class and create that, when it
hit me that the CreateObject wasn't be flagged as an error (and was in
fact already doing what I was thinking I had to do manually , i.e.
reading the class from the registry to find the appropriate DLL) but
the object declaration, just as you note. I tried it as with appWord
declared as Object rather than Word.Application, and once I cleaned up
the constants (e.g. wdDoNotSaveChanges), it compiled OK. After
reading your comments I see I'm on the right track now, and will use
method 2 - develop with the explicit declaration and distribute
without.

As I expected, just cluelessness on my part. Thanks much.
 
J

Jezebel

We must be thinking of different things. If you add Word.9 as a reference to
your project and create an early-bound object, it will fail if the user has
(eg) Word.10. Late binding avoid this problem.
 
H

Howard Kaikow

If you use version N as a reference, the code will work with any later
version.
I do this often.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top