,
(Sorry if this gets posted twice. My Outlook Express seems to be acting
weird. Surprise, surprise!)
(First off I'll admit I wasn't quite right in what I said above. I'll
explain below.)
I runs just fine. I'm not distributing anything but the VB runtime.
I would recommend you check out this article:
Building, Versioning, and Maintaining Visual Basic Components
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvb600/html/msdn_bldvbcom.asp
While Word obviously isn't written in VB, the same basic rules apply. Check
out the section that talks about Compatibility Options in Visual Basic.
Thinking in VB terms, Word's type library (MSWORD.OLB) has always been
recompiled with what amounts to "binary compatibility", so that our programs
could continue to work with newer (or older if we're careful) versions of
Word.
Look in Table 1 in the article where it talks about version numbers of the
type library. If you use OLE View to look at Word's type library
(MSWORD.OLB), you'll find that the Word 97 and Word 2003 versions both have
the same GUID for the type library. Word 97's type library version is 8.0
and Word 2003's is 8.3. (From this we can guess that Word 2000 was 8.1 and
Word 2002 was 8.2). You'll notice the same type of thing with the versioning
if you go look at the various interfaces (classes) in OLE View.
If you want to download OLE View, go here:
http://www.microsoft.com/com/resources/oleview.asp
Here's another really good article:
Visual Basic Design Time Techniques to Prevent Runtime Version Conflicts
http://www.microsoft.com/msj/0100/versioning/versioning.aspx
Now, what this means is that you should never have a problem going FORWARD.
That is, if you compile your VB projects referencing the Word 97 type
library, they will always work no problem with newer versions of Word.
That's the whole point of compatibility. Microsoft wants it to work that
way. If you want to use some methods or objects from newer versions of Word,
use late binding. That is, declare your variables as Object, rather than
Word.Application, for example, and then check the version of Word and call
the methods as needed. You won't get Intellisense, and it will run slighlty
slower, but that's what you gotta do. Now if you ask, "Why don't I just
reference the Word 2003 type library, do version checking and forget about
Diming As Object?" That's where you run into problems!
(OK, I admit, I only just figured this out as I'm writting this!)
It's pretty interesting if you look at the Word 2003 MSWORD.OLB and look at
the Documents interface. You'll see methods called OpenOld, Open2000,
Open2002 and Open. This is because each version of Word has added parameters
to the Open method (OpenOld is Word 97's version). This is because of the
rules of COM, you can't change an all ready published method signature. So
Word 2000 and later add a new Open method, renaming the old one. It's there,
you just can't see it in VB or VBA since its "hidden".
The difficulties come if you compile your VB project while referencing (for
example) the Word 2003 type library. Any calls to Open will be compiled to
use the Word 2003 version of Open. If you then run your project on a Word
97-only system, it will crash with a COM exception, because it is trying to
use a method that does not exist in Word 97. (You can test this for yourself
if you have multiple versions of Word on your machine. Start a quick VB
project, reference a Word 2000 or later Type Library, and call the Open
method. Compile It. Then start Word 97 and run the program, You'll get a
nasty error message.)
Now, as I said, I compiled my project referencing the Word 2000 type library
and it runs fine on Word 97-only systems. Why? Well, two reasons. First,
you'll only have problems if you try to reference methods that have change d
from one version of Word to the next. (The Word help file is happy to tell
you about NEW objects, methods and events, but of course it doesn't tell you
about CHANGED methods, what we are concerned about here.) For example, the
Save method of the Documents object hasn't changed at all up to Word 2003,
so you won't have any problem using it. Second, I used late binding to call
the Open and Add methods of the Documents object. If you use late binding it
will always call the most current version of the method, whatever is happens
to be.
This type of stuff MIGHT explain the difficulties Guy is having using the
ConvertToTable method. The ConvertToTable method has changed from Word 97 to
Word 2000 (parameters where added). If he compiled his project while
referencing the Word 2000 type library, then tried to run it on a Word
97-only machine, he would get an run-time error. Switching to late-binding
(he used CreateObject, etc.) would fix the problem, as it did. The funny
thing is that he compiled under Word 97, in which case he shouldn't have any
problems.
I hope I've explained this well. If not, let me know and I'll try again!
-Tom
