Advice on Debugging Machine-Specific Excel VBA Issue - vba

Question

I have an Excel workbook with dependencies on code in other other Excel workbooks (these dependent .xls's are VB-level references, i.e. via the Tools->References dialog box in the VBA editor), and some dependencies on dll's such as:
Microsoft Scripting Runtime
Microsoft Forms 2.0 Object Library
This sheet has worked for about 2 years on around 20 machines running Windows XP and Office XP. Recently we have taken delivery of 3 new machines (same OS, same office version) which refuse to run this sheet. When the sheet opens, it throws a 'Compile Error', and the session hangs.
If I open the sheet on a 'bad' machine, hold down the left shift key to stop macro's from running, and then go to VBA Editor->Debug->Complie VBAProject, it compiles fine. I am then able to save the sheet and open it normally on a 'bad' machine. However this new version of the sheet refuses to run on a 'good' machine!!
I think there must be some sort of version mismatch between certain dll's on the 'good' and 'bad' machines. How do I establish what is causing the issue? Are there any tools available for comparing versions of com components?

Answer 1

Two suggestions
1) First open the file with macros disabled. And then check VBA Editor | Tools | References. Check for any missing references and then let us know what are they. We will take it from there.
2) For references like "Microsoft Scripting Runtime Object Library" I never use Early Binding. Early Binding is the major cause for these kind of errors. Just FYI: Early Binding is creating references beforehand via VBA Editor | Tools | References. I would recommend changing your code to Late Binding. Here are 2 examples of the same code using "Microsoft Scripting Runtime Object Library" with Early Binding and Late Binding
EARLY BINDING EXAMPLE
'~~> Set Reference to "Microsoft Scripting Runtime Object Library"
Sub EBExample()
Dim FSO As Scripting.FileSystemObject
Dim SourceFolder As Scripting.Folder
Dim FileItem As Scripting.File
Set FSO = New Scripting.FileSystemObject
Set SourceFolder = FSO.GetFolder(SourceFolderName)
For Each FileItem In SourceFolder.Files
'~~> You code
Next FileItem
End Sub
LATE BINDING EXAMPLE
'~~> This doesn't need a reference
Sub LBExample()
Dim FSO As Object, SourceFolder As Object, FileItem As Object
Set FSO = CreateObject("Scripting.FileSystemObject")
Set SourceFolder = FSO.GetFolder(SourceFolderName)
For Each FileItem In SourceFolder.Files
'~~> You code
Next FileItem
End Sub
As for me I use early binding to take advantage of Intellisense but then convert it to late binding to avoid version-specific code before distributing the code. That ways the code always works. :)
IMP NOTE: Late Binding fails in scenarios where the destination machine doesn't have the relevant dll registered.
RECOMMENDED LINK:
Topic: Using early binding and late binding in Automation
Link: http://support.microsoft.com/kb/245115
Hope this helps
Sid

Answer 2

The easiest way I've found to compare references on two different machines is to run a little macro on each pc to show me all the details.
Make sure Excel is set to trust access to the VBA project object model and run the below code on the two versions of your macro.
Sub GetReferences()
Dim r As Object
For Each r In ActiveWorkbook.VBProject.References
Debug.Print r.Name, r.Description, r.FullPath
Next r
End Sub