For Excel 2013, you can type:
o = win32com.client.Dispatch("Excel.Application.15")
since the program is located somewhere like:
C:\Program Files (x86)\Microsoft Office\Office15\EXCEL.EXE
Since I do not have any other version installed, I guess it works if you just replace the 15
by the version you need. You can see the path of the binary that is launched by the command with eg. process explorer.
EDIT: This is impossible "Programmatically" :(
After having tried this:
excel15 = win32com.client.dynamic.Dispatch("Excel.Application.15")
excel14 = win32com.client.dynamic.Dispatch("Excel.Application.14")
which yields objects like this:
>> print excel15
<COMObject Excel.Application.15>
>> print excel14
<COMObject Excel.Application.14>
only one instance of Excel (14) is visible in process explorer. Doing
excel15.Visible = True
confirms that.
It turns out that using automation for controlling both versions of Excel is impossible.
Checking the Registry, the programs (Excel.Application.14
and 15
) share the same CLSID. An there is only one LocalServer
per CLSID (HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer
on my computer).
This LocalServer points to the last installed version, Excel14 (trial) on my computer. This is the only object created by the Dispatch
call.
All this is explained here (§ "Using Automation to Control Microsoft Excel").
There is hope
As I said, this LocalServer
points to the last installed version. There is hence a chance you can achieve what you want:
- either you feel confident to change the registry by hand. I would say "easy" (change the application pointed by
LocalServer
, and the default application of the Excel.Application
entry), but I will prefer the following simple solution
- reinstall the 2007 application (of course, if you can). This is a poor/inelegant yet simple fix.