Path for Winword

[Tom Ellison]

Dear friends:

I am considering a distributable add-in for Access that would need to open
an instance of WinWord.exe. Naturally, the invocation of this requires a
complete path. I have found that in my current registry at:

HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Office
10.0
Word
InstallRoot
Path

Any idea whether this would be the registry key and name to locate the
installed WinWord even if Word were purchased separately, not as a part of
Office?

It is possible there would be an older version of WinWord installed, rather
than 10.0. Any possibility of cataloging for me the versions possible? I
would have to install each one (I have MSDN Universal access to older
versions) and see which ones work with my application. Would each have a
different entry where this says 10.0? Has the key been kept standard across
Word versions?

Likely, I would search the registry for each acceptable version, starting
with the newest and most preferable version. So, I need to generate a list
of keys and search till the first is found (if any). Does this sound like
the standard approach? Any other methods or suggestions would be most
welcome.

Finally, I don't have the dll and function name for this at hand, that is,
to pass the key and name and return the value, the path. I'm sure I can
find it in my resources here, but if you have it close at hand, it would
save me a few minutes. If you don't have it very handy, I'll do it for
myself. Just thought I'd ask.

Thanks, very much, for your time and kindness.

Tom Ellison

 

[Gary Smith]

That registry key is certain to be different for different versions since
to "10.0" is a version number. Could you use something like

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\Winword.exe\shell\open\command

or

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\Winword.exe

instead? These seem to be version-independent.

I am considering a distributable add-in for Access that would need to open
an instance of WinWord.exe. Naturally, the invocation of this requires a
complete path. I have found that in my current registry at:

Any idea whether this would be the registry key and name to locate the
installed WinWord even if Word were purchased separately, not as a part of
Office?

It is possible there would be an older version of WinWord installed, rather
than 10.0. Any possibility of cataloging for me the versions possible? I
would have to install each one (I have MSDN Universal access to older
versions) and see which ones work with my application. Would each have a
different entry where this says 10.0? Has the key been kept standard across
Word versions?

Likely, I would search the registry for each acceptable version, starting
with the newest and most preferable version. So, I need to generate a list
of keys and search till the first is found (if any). Does this sound like
the standard approach? Any other methods or suggestions would be most
welcome.

Finally, I don't have the dll and function name for this at hand, that is,
to pass the key and name and return the value, the path. I'm sure I can
find it in my resources here, but if you have it close at hand, it would
save me a few minutes. If you don't have it very handy, I'll do it for
myself. Just thought I'd ask.

 

[Tom Ellison]

Dear Gary:

That would be an excellent adjustment of my approach. Thanks very much.

Do you have any comment on what would be in that key if there were more than
one version of WinWord installed? The one most recently installed, perhaps?

A drawback to your suggestion would be that I would not be in control of
whether the version of Word I invoke is one of a set that I have tested, and
which work with my application. I will be passing a document name and a
macro of other program name along to Word on the command line. I must test
my macro and other programming against various versions of Word to make
certain they work. I do not want to invoke Word at all if it is not a
sufficiently recent version. That's why I suggested I would likely use a
series of keys, each including one of the various versions of Word that
would work. Does that make sense, too?

So, you see, a version independent implementation is not optimal.

Thanks very much for your time and expertise. I welcome further comment.

Tom Ellison

 

[Gary Smith]

I don't know what happens when there's more than one version installed,
but I suspect that it would be the moest recently installed. I konw there
are people who rad and post in microsoft.public.office.misc who have
multiple versions installed and could tell you for sure.

If you need to ensure that you have one of a specific set of versions,
then a version-independent technique isn't going to work for you. In that
case, your original approach would seem to be the better bet, but I can
see problems in attempting to get the right answer.

On my system, registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office
has three subkeys named 8.0, 9.0, and 11.0. The 8.0 entry may be there
because I once had Office 97 installed. I don't recall for sure
whether it was installed on this machine. The 9.0 entry is from Office
2000, which is the installed version. The 11.0 is from the Office 2003
Word viewer. There's never been an actual Office 2003 component on this
machine.

Fortunately, the 11.0 key has no Word subkey, so that owuldn't confuse
your application. Both the 8.0 and 9.0 keys have Word subkeys, and each
of those has an InstallRoot subkey. The Path values of those two
InstallRoot keys are identical except that one is in quotation marks and
the other isn't -- probably not a significant difference.

Based on this data, I don't see how you could be sure which version of
Word is installed. I suspect that if I has installed 97, then 2000, then
uninstalled 2000 and reinstalled 97, the registry would look much the
same. Do you have a way to check the version by looking at Winword.exe
itself?

Dear Gary:

That would be an excellent adjustment of my approach. Thanks very much.

Do you have any comment on what would be in that key if there were more than
one version of WinWord installed? The one most recently installed, perhaps?

A drawback to your suggestion would be that I would not be in control of
whether the version of Word I invoke is one of a set that I have tested, and
which work with my application. I will be passing a document name and a
macro of other program name along to Word on the command line. I must test
my macro and other programming against various versions of Word to make
certain they work. I do not want to invoke Word at all if it is not a
sufficiently recent version. That's why I suggested I would likely use a
series of keys, each including one of the various versions of Word that
would work. Does that make sense, too?

So, you see, a version independent implementation is not optimal.

 

[Tom Ellison]

Dear Gary:

Thanks very much for your views!

I don't know if I care which was installed in what order. It's good to know
to check whether it is really installed at all, or may have been
uninstalled. I'll need to check on that.

I don't think you are intending to make an authoritative statement about
whether the subkeys are always the same as I reported initially, except for
the version number. You're just saying that your system has them much like
mine does. That's somewhat helpful, anyway.

I believe I'll go ahead and start building this. When it later fails, I
just hope I can remember all the assumptions I made so I can quickly find
problems and fix them. I guess there will be a number of comments in the
code for this, and I should keep a document log of them as well.

That's not how I'd prefer to go!

Tom Ellison

 

[Dave Patrick]

Something like this may work.

Public Function WordVersion()
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
Select Case WshShell.RegRead("HKCR\Word.Application\CurVer\")
Case "Word.Application.8"
WordVersion = 8
Case "Word.Application.9"
WordVersion = 9
Case "Word.Application.10"
WordVersion = 10
Case "Word.Application.11"
WordVersion = 11
End Select
End Function

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Dear friends:
|
| I am considering a distributable add-in for Access that would need to open
| an instance of WinWord.exe. Naturally, the invocation of this requires a
| complete path. I have found that in my current registry at:
|
| HKEY_LOCAL_MACHINE
| SOFTWARE
| Microsoft
| Office
| 10.0
| Word
| InstallRoot
| Path
|
| Any idea whether this would be the registry key and name to locate the
| installed WinWord even if Word were purchased separately, not as a part of
| Office?
|
| It is possible there would be an older version of WinWord installed,
rather
| than 10.0. Any possibility of cataloging for me the versions possible? I
| would have to install each one (I have MSDN Universal access to older
| versions) and see which ones work with my application. Would each have a
| different entry where this says 10.0? Has the key been kept standard
across
| Word versions?
|
| Likely, I would search the registry for each acceptable version, starting
| with the newest and most preferable version. So, I need to generate a
list
| of keys and search till the first is found (if any). Does this sound like
| the standard approach? Any other methods or suggestions would be most
| welcome.
|
| Finally, I don't have the dll and function name for this at hand, that is,
| to pass the key and name and return the value, the path. I'm sure I can
| find it in my resources here, but if you have it close at hand, it would
| save me a few minutes. If you don't have it very handy, I'll do it for
| myself. Just thought I'd ask.
|
| Thanks, very much, for your time and kindness.
|
| Tom Ellison
|
|

 

[Tom Ellison]

Dear Dave:

Thanks very much. I'll see about fitting that in.

Tom Ellison

 

[Dave Patrick]

You're welcome.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Dear Dave:
|
| Thanks very much. I'll see about fitting that in.
|
| Tom Ellison

 

[Gary Smith]

That will certainly give the right answer on my system. If a system has
multiple versions of Word installed, it will probably give the most
recently installed version, which ought to be the newest one since
installing an older version on a system that already has a newer one would
probably break the newer one. At any rate, systems with multiple
versions of Word are so rare that they can probably just be ignored.

 

[Dave Patrick]

When you install multiple version of Access then the most recently used is
what populates the 'CurVer' subkey. Yes I would agree that a multi version
install of word would be rare (not sure why anyone would want to)

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| That will certainly give the right answer on my system. If a system has
| multiple versions of Word installed, it will probably give the most
| recently installed version, which ought to be the newest one since
| installing an older version on a system that already has a newer one would
| probably break the newer one. At any rate, systems with multiple
| versions of Word are so rare that they can probably just be ignored.