Okay, I just ttried to get at the anatomy of the registry entries and one point is clear, when you first look up the 'Excel.Application.10' that's finding a CLSID in one branch of HKEY_CLASSES_ROOTI just compiled my.exe with an application class that's olepublic and thus I find my.application here:
[pre]------------------------------------------------
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\my.application]
@="my.application"
[HKEY_CLASSES_ROOT\my.application\CLSID]
@="{BA5.....}"
[HKEY_CLASSES_ROOT\my.application\NotInsertable]
------------------------------------------------[/pre]
And for that CLSID I then find the detail information:
[pre]------------------------------------------------
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}]
@="my.application"
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\Foxruntime]
@="VFP9R.DLL"
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\Implemented Categories]
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\Implemented Categories\{40FC...}]
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\LocalServer32]
@="c:\\programming\\tek-tips\\my\\my.exe /automation"
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\ProgId]
@="my.application"
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\Programmable]
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\TypeLib]
@="{275E9555-47DF-4D93-927C-ED8058590DAA}"
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\Version]
@="1.0"
[HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{BA5.....}\VersionIndependentProgId]
@="my.application"
------------------------------------------------[/pre]
In the ProgID branch the ProgId "my.application" is repeated, so it confirms what I was searched for initially in HKEY_CLASSES_ROOT is represented by this CLSID and then the LocalServer32 key states what to run...my.exe
The registry branches may look slightly different for Office applications, but the main keys are the LocalServer32 stating what to run and the ProgId within the CLSID branch that matches the HKEY_CLASSES_ROOT\<<ProgId>>\CLSID key.
If two excel versions Excel.Application.X and Excel.Application.Y point to the same CLSID that will make both run the same actual EXE, even though the ProgId subkey of that CLSID will only match the inital ProgID you specify in your CREATEOBJECT(). That's I think what happens, and there's nothing you can do about that, as you don't determine CLSIDs.
It's not that way in general, that CLSIDs stay the same for different versions of an automation server, but if they do, the root entries in HKEY_CLASSES_ROOT can only point to one CLSID branch of HKEY_CLASSES_ROOT\WOW6432Node\CLSID and that will then only contain one ProgID sub key and one LocalServer32 key, so both version specific classes run the same EXE, which means the version specific class names become version unspecific.
You don't control how CreateObject() works and I think the VFP runtime also has no say when it comes to delegating OLE to find the LocalServer32 to run starting from a ProgID, how the lookup of that in the registry is done. It should be a generally known problem, I now also find another forum thread in excelforum.com stating Excel.Application.8 has the same CLSID as Excel.Application.9, so this seems to apply to all Excel versions and desppite version specific ProgIds they all point to the same EXE and whatever is specified for that CLSID runs.
So, yes, central point is the same CLSID. I can't search your registry for whether you find the version specific progids in other CLSIDs, though. I wonder why MS insisted on the constant CLSID for Excel.Application, I don't know how that is for other Office applications, but I think I ran different Word versions where that was necessary.
Chriss
