Yes, I remember now.
I have used such an approach on other components with success, but forgot
that it does not work with Office apps.

Actually, I have added an context menu entry to open Excel files in the
non-current version:

HKEY_CLASSES_ROOT\Applications\EXCEL.EXE\shell\Ope n in Previous XL
version\command
"C:\Program Files\Microsoft Office\Office 2000\Office\EXCEL.EXE" "%1"

You could add one for each version you have.
OK not automation, but easy to specify the Excel version you want to work
with.

Maybe if you

wrote in message
ps.com...
That's what I thought, and was what I initially tried. But the
"Additional Notes" on this page:

http://support.microsoft.com/kb/292491

seems to indicate that this is not the case. It specifically warns
that doing it this way will not operate as expected. Quote:

"A common perception for Office Automation when you have multiple
versions of Office installed on a system is that you can dictate which
version loads by using a specific version-dependent PROGID (for
example, that "Excel.Application.9" loads Excel 2000,
"Excel.Application.10" loads Excel 2002 and "Excel.Application.11"
loads Office Excel 2003). However, this is not correct. Excel 2000 and
later versions of Excel share the same CLSID, so the version that
loads with these PROGIDs depends solely on which version was last
installed."



On Jun 7, 3:57 pm, "NickHK" wrote:
CreateObject can take an optional version indicator e.g.
Excel.Application.8
and as it is a string, you can build it in a loop:

Private Sub CommandButton1_Click()
Dim i As Long
Dim XLApp As Object

For i = 8 To 12
On Error Resume Next
Set XLApp = CreateObject("Excel.Application." & i)
On Error GoTo 0

If Not XLApp Is Nothing Then
'.......whatever
XLApp.Quit
Set XLApp = Nothing
Else
Debug.Print "Excel verion " & i & " is probably not installed."
End If
Next

End Sub

NickHK