In my program I have to load a excel-file. This file can have the following extensions: [.xls][.xlsx][.xlsm][.xlsb].
Excel07+ can handle all of these by nature, but to work with [.xlsx][.xlsm][.xlsb] in Excel2003 you have to install the http://www.microsoft.com/en-us/download/details.aspx?id=3
Here is my code to determine, which excelversion is installed. Problem: I don´t know how to determine an installation of the compatibility pack (marked by +++)
if (ExtractFileExt(sFileNameVorlage) = '.xlsx') or
(ExtractFileExt(sFileNameVorlage) = '.xlsm') or
(ExtractFileExt(sFileNameVorlage) = '.xlsb') then
begin
//determine version of excel (lower or equal 2003 )
if StrToInt(Copy(oVersionscheck.version,1,2)) <= 11 then
begin
// equal 2003
if StrToInt(Copy(oVersionscheck.version,1,2)) = 11 then
if not +++compatibility pack installed?+++ then
begin
ShowMessage('Warning: Excel can´t open this file.');
oVersionscheck.Quit;
oVersionscheck := unassigned;
Exit;
end;
end;
oVersionscheck.Quit;
end;
Perhaps someone knows a solution.
I have found the following answer at http://www.tech-archive.net/Archive/Word/microsoft.public.word.vba.general/2008-10/msg00682.html
This is a VBA function, so you may need to translate it to your programming language of choice. (In more modern languages use Try/Catch clause instead of "On Error Resume Next")
Function Office2007CompatibilityInstalled()
'Checks whether in Office 2003 the compatibility pack for Office 2007/2010 is installed
Dim WSHShell, RegKey, rKeyWord, Result
Set WSHShell = CreateObject("WScript.Shell")
RegKey = "HKEY_CLASSES_ROOT\Installer\Products\00002109020090400000000000F01FEC\"
On Error Resume Next 'This is in an anticipation of what may happen in the next line
'The next line will generate an error if the registry key does not exist.
'This error will be ignored and execution will continue with the line following
'it (because of "On Error Resume Next" statement). In this case the value of
'rKeyWord will remain uninitialised.
rKeyWord = WSHShell.RegRead(RegKey & "ProductName")
'In the line below we compare the value of rKeyWord to a fixed string which we
'know to denote that Office2007 Compatibility Pack has been installed.
'If the registry key did not exist then the value of rKeyWord will be uninitialised
'and will be automatically converted to an empty string ("") for the purposes
'of this comparison.
If rKeyWord = "Compatibility Pack for the 2007 Office system" Then
Office2007CompatibilityInstalled = True
End If
End Function
Related
In VBA I can see three different references for PDFCreator. One of them (see the second image) is a version of the software stored locally, and it works. I'd like to use this reference.
The other two are references to versions stored on a server, and they're broken (at this stage, I don't have permission to reinstall or delete them).
My problem is that after selecting the desired reference (see the second image) and clicking 'Ok', it resets to an incorrect reference, as shown in the third image.
How can I either override whatever's going on and select the desired reference or remove the incorrect references? While I'm not able to uninstall these versions from the server, I see no reason that my Excel would need to reference them. Can they just be removed from the list?
Image 1: Default state of the VBA Project References (PDFCreator not selected)
Image 2: Selecting the correct PDFCreator version
Image 3: Re-opening the menu shows that the incorrect PDFCreator version is selected
You might be able to something like the following...
To Remove broken references:
Private Sub RemoveBrokenReferences(ByVal Book As Workbook)
'////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Dim oRefS As Object, oRef As Object
'////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Set oRefS = Book.VBProject.References
For Each oRef In oRefS
If oRef.IsBroken Then
Call oRefS.Remove(oRef)
End If
Next
End Sub
To Remove a specific reference:
Use something like:
Call ActiveWorkbook.VBProject.References.Remove(oReference)
and you can get the oReference from:
Private Function GetReferenceFromPath(ByVal FilePathName As String) As Object
'////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Dim oFs As Object, oReferenceS As Object, oReference As Object
Dim sFileName As String, sRefFileName As String
'////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Set oFs = Interaction.CreateObject("Scripting.FileSystemObject")
sFileName = oFs.GetFileName(FilePathName)
Set oReferenceS = ActiveWorkbook.VBProject.References
For Each oReference In oReferenceS
sRefFileName = oFs.GetFileName(oReference.FullPath)
If StrComp(sFileName, sRefFileName, vbTextCompare) = 0 Then
Set GetReferenceFromPath = oReference
End If
Next
End Function
Public Sub RemoveReference()
On Error GoTo EH
Dim RefName As String
Dim ref As Reference
RefName = "Selenium"
Set ref = ThisWorkbook.VBProject.References(RefName)
ThisWorkbook.VBProject.References.Remove ref
Exit Sub
EH:
'If an error was encountered, inform the user
Select Case Err.Number
Case Is = 9
MsgBox "The reference is already removed"
Exit Sub
Case Is = 1004
MsgBox "You probably do not have to have Trust Access To Visual Basic Project checked or macros enabled"
Exit Sub
Case Else
'An unknown error was encountered
MsgBox "Error in 'RemoveReference'" & vbCrLf & vbCrLf & Err.Description
End Select
End Sub
P.S It is not possible to remove A MISSING/ broken references programmatically after MISSING occurs, only before it happens or manually after it happens. Most cases of MISSING/ broken references are caused because the type library has never before been registered on that system.
See How to Remove Reference programmatically?
I had a broken reference problem with a large number of Excel spreadsheets when I uninstalled Flash (which for some unknown reason I had included as a reference).
I got round the problem as follows:
BE CAREFUL BECAUSE THIS INVOLVES A REGISTRY HACK AN IS COMPLICATED.
MAKE A BACKUP OF REGISTRY BEFORE HACKING.
I wrote VBA code to find the Guid of the broken reference.
I used Regedit to insert a DUMMY TypeLib entry as follows:
D27CDB6B-AE6D-11CF-96B8-444553540000 was the Guid of the Broken Reference.
HKEY_CLASSES_ROOT\TypeLib{D27CDB6B-AE6D-11CF-96B8-444553540000}
HKEY_CLASSES_ROOT\TypeLib{D27CDB6B-AE6D-11CF-96B8-444553540000}\1.0 Adobe Acrobat 7.0 Browser Control Type Library 1.0
HKEY_CLASSES_ROOT\TypeLib{D27CDB6B-AE6D-11CF-96B8-444553540000}\1.0\0
HKEY_CLASSES_ROOT\TypeLib{D27CDB6B-AE6D-11CF-96B8-444553540000}\1.0\0\win32 C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX\AcroPDF.dll
HKEY_CLASSES_ROOT\TypeLib{D27CDB6B-AE6D-11CF-96B8-444553540000}\1.0\FLAGS 0
HKEY_CLASSES_ROOT\TypeLib{D27CDB6B-AE6D-11CF-96B8-444553540000}\1.0\HELPDIR C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX\
I based the above on another TypeLib entry.
Then I wrote VBA code to read each Reference.Guid in turn and if the Guid matched {D27CDB6B-AE6D-11CF-96B8-444553540000} to remove the reference using References.Remove Reference.
Code for doing this is available all over the forums so I won't repeat here.
After modifying all the affected Workbooks I reinstated the saved registry.
Hope this works for you.
BE CAREFUL BECAUSE THIS INVOLVES A REGISTRY HACK AN IS COMPLICATED.
MAKE A BACKUP OF REGISTRY BEFORE HACKING.
We have a module that checks for machine information for troubleshooting purposes. One of the sub modules checks each reference for breaks. However for a single reference, the Microsoft Office Soap Library 3.0 it halts on an error.
We can work around it, but I'm really interested to know what is causing this error. The reference is valid, not broken. The method of the reference object simply fails for this library.
Method 'FullPath' of object 'Reference' failed
Private Sub getEachRef()
Dim ref As Variant
Dim strRef As String
'On Error Resume Next <- this allows the rest of the code to complete
For Each ref In Application.VBE.ActiveVBProject.References
frmAbout.lst_About.AddItem "[Reference] " & ref.Description
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 1) = ref.FullPath <- error is here
If ref.IsBroken = True Then
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 2) = "Broken Link"
End If
Next
End Sub
I run into this posting as I got the same error myself.
I've been able to trace the issue with your problem as follows:
The Error Number returned is: -2147319779
Code compiles without errors
(as mentioned in the posting) The reference is valid, not broken
(meaning that when you check your listed references, the reference(s)
is (are) not Listed as 'Missing' or if checked through VBA, is not listed as 'Broken')
I've read some other postings in other forums where even the code/VBA
application (MsAccess) actually runs without problems in 'one' PC
(PC 01) and returns the 'error' in another PC (PC 02)
I've been able to replicate this phenomena myself.
After comparing PC 01 with PC 02 you see that both PCs though may
actually have the 'same' exact version of MsAccess/Excel installed +
the same MsAccess (or Office) Service Pack installed but once you start to test each and everyone of the applied patches (this can be a
long process), you will find that some Dlls have actually NOT been replaced/patched, updated.
In my case, those affected PCs (that will NOT run the Code, thus produce an error), each had a different cause (different, not properly updated dll), thus there is NOT a 'universal' 'replace the following dlls' to repair the problem.
That said however, there is a solution (so enough of trying to explain):
1st Solution (least invasive)
Repair MsAccess/Office Installation.
When completed, re-apply latest Service Pack + all Office Updates.
This solution in 'some pcs' resolved the issue, ie. VBA Code run without problems.
If Repair MsAccess/Excel/Office Installation failed (due to Error
2424, 2425, or repair fails), then, proceed to solution Nmr. 2 (no
pun intended : D )
2nd Solution (middle group invasive)
Uninstall MsOffice completely (including all updates, Service Packs, etc.)
Will need a clean reboot after the uninstallation has completed.
After the uninstall process has completed and the PC has been rebooted, then install MsOffice again (including all updates, Service Packs, etc.)
This solution actually worked on another sub-set of affected PCs I found.
If uninstall of MsAccess/Excel/Office failed (due to the same
previous Errors 2424, 2425, or repair fails, etc), then, proceed to
solution Nmr. 3 (the nuclear option)
3rd Solution (nuclear option)
Download and Install 'Microsoft Office 2010 FixIt Tool' (or the version that may apply to your situation) https://support.microsoft.com/en-us/office/repair-an-office-application-7821d4b6-7c1d-4205-aa0e-a6b40c5bb88b?ocmsassetid=ha010357402&ctt=1&correlationid=8bfaf910-6d5f-4252-b5bb-0ed67d5d4349&ui=en-us&rs=en-us&ad=us
Run Tool to remove MsOffice 2010 completely. Once completed (PC will
need to be rebooted after the tool is finished with the cleanup/deinstallation)
Reboot PC after MsOffice 2010 (or the version that may apply to your
situation) removal has been completed (this step is very important)
Install MsOffice/MsAccess/Excel 2010 (or the version that may apply to your situation) again.
Install Language Packs (if needed).
Install the latest Service Pack ie. Service Pack 1, Service Pack 2, etc.
This solution actually fixed the 3rd group of affected PCs I had. That said however, after a 'clean' install of MsOffice, some PCs, then got a different error:
Ms Access/Excel Can't Open your previous application.
This error ONLY was found on PCs that had gone through the 3rd Option (though MsOffce and MsAccess 'seem' to work just fine and even the original 'Issue' as described in this posting was 'fixed' meaning that the code run without the Method 'FullPath' of Object Reference failed problem, then the 'new' problem was found as those 'latest' installs of MsOffice (2010 and later) seem to apply updates/service packs differently from commulative updates, vs. clean installs + latest updates/service packs.
4rth Option - Trapping the error
I'm using the same exact code as an example (see above) and insert an 'Error Trapping' Section as follows (I'm copying the entire code and pasting the completed module including the error trapping part):
Private Sub getEachRef()
On Error GoTo getEachRef_Err
Dim ref As Variant
Dim strRef As String
'On Error Resume Next <- this allows the rest of the code to complete
For Each ref In Application.VBE.ActiveVBProject.References
frmAbout.lst_About.AddItem "[Reference] " & ref.Description
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 1) = ref.FullPath '<- error WAS here
getEachRef_Ressume01:
If ref.IsBroken = True Then
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 2) = "Broken Link"
End If
Next
getEachRef_Exit:
Exit Sub
getEachRef_Err:
Select Case Err.Number
Case -2147319779
getEachRef_Ressume01
Case Else
MsgBox Err.Number & Err.Description
Resume getEachRef_Exit
End Select
End Sub
This code sample allows the existing code to simply 'jump' over the 'error' and continue :).
In my case, after I had some PCs with Solution No. 1, others with No. 2 and No. 3.. on any new instances, since I implemented the above 'error trapping' into the module, no more errors have been produced anywhere else.
Just to be clear, with solution No. 4, the 'error' is NOT fixed but is simply bypassed and allowed the code to continue to execute the loop.
In my case, I added some more Code into the VBA to show the 'major' version and 'minor' version of the ref.FullPath in the above code that could not be shown (so that at least I can see what was bypassed by the code).
Private Sub getEachRef()
On Error GoTo getEachRef_Err
Dim ref As Variant
Dim strRef As String
For Each ref In Application.VBE.ActiveVBProject.References
frmAbout.lst_About.AddItem "[Reference] " & ref.Description
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 1) = ref.FullPath '<- error WAS here
getEachRef_Ressume01:
If ref.IsBroken = True Then
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 2) = "Broken Link"
End If
Next
getEachRef_Exit:
Exit Sub
getEachRef_Err:
Select Case Err.Number
Case -2147319779
getEachRef_Ressume01
Case Else
MsgBox Err.Number & Err.Description
Resume getEachRef_Exit
End Select
End Sub
I have been using folder browser for VBA, I could paste the code of it, but bottom line is that I get returned file name as a string.
Is there any way to access drawing properties (i.e number of layouts) without open?
Public Sub TestFileDialog()
dwgname = FileBrowseOpen("C:", "*", ".dwg", 1) 'dwgname is typeof string
End Sub
Its only the first step (use of FileBrowseOpen function is shown, but also i can use FolderBrowse and collect all .dwg inside of folder),actually i had in mind to batch export all layouts of selected .dwgs to currenty open one. Is there any chance for that?
To effectively read a .dwg file you'll need to open AutoCAD, otherwise the information is not accessible. Some properties may be, such as author, but not number of layouts...
But you can use AutoCAD Console (accoreconsole.exe) to run a headless AutoCAD and use APIs to read any information you need. This is really fast for reading lot's of files and the user will not see it running (but it needs to be installed anyway).
http://aucache.autodesk.com/au2012/sessionsFiles/3338/3323/handout_3338_CP3338-Handout.pdf
you could stay in VBA and use ObjectDBX
it leads to a very similar approach as accoreconsole.exe on in .NET does, i.e you won't see any drawing open in UI since it works on the database itself
It requires adding library reference (Tools->References) to "AutoCAD/ObjectDBX Common XX.Y Type Library", where "XX.Y" is "19.0" for AutoCAD 2014
a minimal functioning code is
Sub main()
Dim myAxDbDoc As AxDbDocument
Dim FullFileName As String
FullFileName = "C:\..\mydrawing.dwg" '<== put here the full name of the file to be opened
Set myAxDbDoc = AxDb_SetDrawing(FullFileName)
MsgBox myAxDbDoc.Layers.Count
End Sub
Function AxDb_SetDrawing(FullFileName As String) As AxDbDocument
Dim DBXDoc As AxDbDocument
Set DBXDoc = Application.GetInterfaceObject("ObjectDBX.AxDbDocument.19") '<== place correct AutoCAD version numeber ("19" works for AutoCAD 2014)
On Error Resume Next
DBXDoc.Open FullFileName
If Err <> 0 Then
MsgBox "Couldn't open" & vbCrLf & vbCrLf & FullFileName, vbOKOnly + vbCritical, "AxDB_SetDrawing"
Else
Set AxDb_SetDrawing = DBXDoc
End If
On Error GoTo 0
End Function
Still, you must have one AutoCAD session running from which make this sub run! But you should have it since talked about "currently open" drawing
I have a .dot file with one line of code that must be executed in a Microsoft Word macro if and only if the version of Word 2003 or greater is installed, otherwise it shuold be ignored. I tried to implement it like this, hoping that Visual Basic for Word compiles a line only if it needs to execute it. The code in question is the following (Word 2003 is 11.0)
If Val(Application.Version) >= 11 Then
ActiveWindow.View.ReadingLayout = False
End If
I still want that the .dot file with the macro is usable in earlier versions of Microsoft Word, such as Microsoft Word 2000.
However, if I try to run the .dot file, it fails on Word 2000 with a compile error because ActiveWindow.View.ReadingLayout is not a valid method in Word 2000. That is, even when the line will never be executed on Word 2000 because Application.Value will be 9.0, Word still tries to compile that line.
Is there any way in Visual Basic for Word to add compiler directives so that some code is not compiled depending on the Word version?
We ended up implementing it with late binding, which turned out to be a very small tweak:
If Val(Application.Version) >= 11 Then
Dim obj As Object
Set obj = GetObject(, "Word.Application")
obj.ActiveWindow.View.ReadingLayout = False
End If
Their are two tricks to get it working:
1)
Add a module for functions that work only in specific office version and add your subroutines to it.
2)
In places where you have to call your functions, add a test for the specific Office Version and then call your subroutine with Application.Run
The original Module would have:
If Val(Application.Version) >= 11 Then
Application.Run "office11module.disableReadingLayout"
End If
And your specific Module office11module would have
Public Sub disableReadingLayout()
ActiveWindow.View.ReadingLayout = False
End Sub
This works because Word is not compiling the office11module until it is needed, and we make sure through the Application.Run call that Word does not know that we need it before runtime.
Our Word VBA Products require a Digital Signature.
We utilize MS Office 2000 as a base development application in order to be as backward compatible as possible with some of our clients.
We utilized the solution provided by jonas_jonas (Jan 16 '14 at 17:59) for years while using Word 2000 on Windows XP development platforms.
However - after upgrading to Windows 7 Pro development platforms, the solution no longer worked, giving us "Disk full" errors when attempting to save the Word files after having digitally signed them.
We then tried, and successfully used, the answer (above) provided by Pep (Jan 18 '14 at 23:23) which works when you need to Digitally Sign the Word file.
We figured the "disk full" error was a result of the attempt to compile the project before saving.
If Val(Application.Version) >= 11 Then
Dim obj As Object
Set obj = GetObject(, "Word.Application")
obj.ActiveWindow.View.ReadingLayout = False
End If
I have both Word 2007 and 2010 installed. I need to open Word from within Excel but I need to specify which version I need to open within VBA.
I've tried late binding
Dim wordApp2007 As Object
Dim wordApp2010 As Object
Set wordApp2007 = CreateObject("Word.Application.12")
wordApp2007.Visible = True
Set wordApp2010 = CreateObject("Word.Application.14")
wordApp2010.Visible = True
but both open Word 2010
I've also tried early binding by using
Dim wordApp As Word.Application
Set wordApp2007 = New Word.Application
wordApp2007.Visible = True
and setting references to the Word 12.0 object model but this still opens Word 2010
If I register each version of Word using
"C:\Program Files\Microsoft Office\Office12\WINWORD.EXE" /regserver
"C:\Program Files\Microsoft Office\Office14\WINWORD.EXE" /regserver
then the version registered opens but then I can't open open the non-registered.
Can anyone help and show me how to open a specific version of Word within Excel using VBA?
Thank you
Edit: Example code....
Option Explicit
Dim wordApp2007 As Word.Application
Sub Word_InfoEarly()
'early binding
Set wordApp2007 = New Word.Application
wordApp2007.Visible = True
'other Stuff
Stop
wordApp2007.Quit
Set wordApp2007 = Nothing
End Sub
Sub Word_InfoLate()
Dim wordApp2007 As Object
Dim wordApp2010 As Object
Set wordApp2007 = CreateObject("Word.Application.12")
wordApp2007.Visible = True
Set wordApp2010 = CreateObject("Word.Application.14")
wordApp2010.Visible = True
'other Stuff
Stop
wordApp2007.Quit
Set wordApp2007 = Nothing
wordApp2010.Quit
Set wordApp2010 = Nothing
End Sub
This is a work around:
TaskID = Shell("C:\Program Files\Microsoft Office\Office12\WINWORD.EXE",vbHide) '2007
'TaskID = Shell("C:\Program Files\Microsoft Office\Office14\WINWORD.EXE",vbHide) '2010
GetObject(,"Word.Application")
You would also need to test if a previous version of word is open, or use something other than a basic GetObject to activate the window, else there's no guarantees that it will get the right version.
The other way would be to pass the document name in the Shell command, and then GetObject could be called with the document name
This may further explain why the code works some times and not others.
My observation on the situation of the command
'Set wordAppxxxx = CreateObject("Word.Application.xx")'
working or not on your computer is that it is a function of the latest update you get from Microsoft.
Why I believe this:
I have an application that converts a text file to a Word document for backwards compatibility with some legacy apps. The best plan includes using a version of Word similar to the version the legacy apps were designed with/to. As a result, I searched on how to invoke a legacy version of Word as opposed to the default offering on my computer which is Word 2010.
The solution noted in this discussion chain provided the answer to my question. (Thank you Stack Overflow contributors!) I wanted to use Word XP, so I looked at my directories and observed that Word XP (aka Word 2002) is a member of Office 10, so I created the command
'Set wordApp2002 = CreateObject("Word.Application.10")'
and my program launched Word 2002 and the world was a happy place.
Over the weekened, I had an update to my computer. I control the updates via an app which gives me control over when updates occur such that I can observe changes to my configuration. This morning (9/30/13) I turned on a computer that had a Word update. I did not know this until after I had made one run of my app from last week. The app ran fine and invoked Word 2002 as expected.
But then I got the banner page informing me of a Word 2010 update that was installing itself.
Afterwards, I ran the app that worked so well for me last week and once today. Now, after the Word update (immediately after!), the same code now launches Word 2010 despite the fact that the command line invoking Word 2002 has not changed.
This appears strong evidence that a Microsoft update tweaked the settings that previously allowed the VB code to work as expected. This might be a good item to bring to Microsoft's attention so see if we can get this item stabilized in subsequent update packages to allow consistent behavior in future releases.
I hope this is helpful,
JeffK
I wasted half a day on this, and want to help prevent others doing the same! I'm running Windows 7 and Office 2013 and 2010 on the same laptop. I wanted to get Access VBA to open up an old version of Word, as Word 2013 call-outs are printing with thick black borders.
Having tried lots of variations, here's my code which worked:
Sub GetWordReference()
'finally got Access to open old version of Word
'open Word 2010
Shell "C:\Program Files (x86)\Office 2010\Office14\winword.exe"
'open Word 2013
'Shell "C:\Program Files\Microsoft Office 15\root\office15\winword.exe"
TryAgain:
On Error GoTo NoWord
Set word2010 = GetObject(, "Word.Application")
On Error GoTo 0
word2010.Visible = True
'word2010.Documents.Add
'word2010.Selection.TypeText "This is Word " & word2010.Version
Exit Sub
NoWord:
Resume TryAgain
End Sub
I can't get the SO code editor to show this correctly, but copying and pasting should work.
I had a similar issue, and thought I would detail my experience for those that stumble across this in the future.
In my situation, I had a Powerpoint macro that was supposed to open a file dialog for the user to select some Excel files and then create tables from the data; I had no problem with it until I recently installed Excel 2003. Now Powerpoint was opening up an Excel 2003 file dialog, which would raise errors when trying to select a *.xlsx file. It didn't matter if I used Excel.Application.10 or Excel.Application.14 in my code to create the Excel object, it was always an Excel 2003 file dialog.
I noticed in Explorer that *.xlsx files were set to be opened in Excel 2010 and *.xls files were set to be opened in Excel 2003. I tried to usual way to reset *.xls files to be opened in 2010 to no avail. I ended up having to delete the registry key and repair Office 2010. Now that all Excel files open in 2010, my problem has been fixed.
I know my problem was a bit different than yours, but I think my experience could help lead to a solution. I think any solution will end up relying on some registry editing.
This is a VB.NET solution:
Sub Word_InfoLate()
Dim wordApp2007 As Object
Dim wordApp2010 As Object
This is a bit intimidating to some, but there may be a registry edit that can solve this.
I am unable to test as I only have one version of MS Office available to me, however, previous versions still have registry keys left over.
I found the 2007 version of Word in the registry, and it's default location is C:\program Files\Microsoft Office\Office14\WINWORD.EXE" indicating that older versions of Word are registered to the newest version install location as it's new default.
What you might be able to do is navigate to the registry location
HKEY_CLASSES_ROOT\Word.Documet.12\shell\Open\Command
Change the (Default) key to read "C:\program Files\Microsoft Office\Office12\WINWORD.EXE" /n "%1"
In theory whenever
Set wordApp2007 = CreateObject("Word.Application.12")
is invoked it may probe the registry for the location of the executable, and find the correct path.