Question

FINAL EDIT: It does indeed appear to be a compiler bug – see the accepted answer.

Using VBA within Excel 2007, I have the following code in ‘Class1’:

Option Explicit

Public Function strange(dummy As String, ParamArray pa())
    Debug.Print pa(LBound(pa))
End Function

Public Sub not_strange(dummy As String, ParamArray pa())
    Debug.Print pa(LBound(pa))
End Sub

Public Function also_not_strange(ParamArray pa())
    Debug.Print pa(LBound(pa))
End Function

and some mode code in a module:

Option Explicit

Public Function not_strange_either(dummy As String, ParamArray pa())
    Debug.Print pa(LBound(pa))
End Function

Public Sub outer(v)
    Dim c As Class1
    Set c = New Class1

    Call c.strange("", v(LBound(v)))
    Call c.not_strange("", v(LBound(v)))
    Call c.also_not_strange(v(LBound(v)))

    Call not_strange_either("", v(LBound(v)))
End Sub

If call ‘outer’ from the Immediate window like this:

call outer(array("a"))

I get back output that seems strange:

 102085832 
a
a
a

It seems to matter whether the called routine is in a class module or not, whether it is a Sub or a Function, and whether or not there is an initial argument. Am I missing something about how VBA is supposed to work? Any ideas?

The strange number changes from run to run. I say “looks suspiciously like a pointer” because if I call this:

Public Sub outer2(v)
    Dim c As Class1
    Set c = New Class1

    Dim ind As Long
    For ind = LBound(v) To UBound(v)
        Call c.strange("", v(ind))
    Next ind
End Sub

like so:

call outer2(array("a","b","c"))

I get back output like:

 101788312 
 101788328 
 101788344 

It’s the increment by 16 that makes me suspicious, but I really don’t know. Also, passing a value, say by calling:

Call c.strange("", CStr(v(ind)))

works just fine.

EDIT: A little more info…If I assign the return value from ‘c.strange’ to something instead of throwing it away, I get the same behavior:

Public Sub outer3(v)
    Dim c As Class1
    Set c = New Class1

    Dim x
    x = c.strange("", v(LBound(v)))

    Call c.not_strange("", v(LBound(v)))
    Call c.also_not_strange(v(LBound(v)))

    Call not_strange_either("", v(LBound(v)))
End Sub

Interestingly, if I call my test routines as above, with an argument that results from calling ‘Array’, the supposed-pointer value changes. However, if I call it like this:

call outer([{1,2,3}])

I get back the same number, even if I make the call repeatedly. (The number changes if I switch to another app in Windows, like my browser.) So, now I’m intrigued that the Excel evaluator (invoked with the brackets) seemingly caches its results…

Answer 1

Now this is awesome.

Reproduced on office 2003.
Looks like a compiler bug.

The problem is in this line:

Call c.strange("", v(LBound(v)))

Here the compiler creates a Variant that holds a 1D array of Variant‘s, the only element of which is a pointer instead of the value. This pointer then goes to the strange function which actually is not strange, it only prints the Variant\Long value passed to it.

This trick brings the compiler sanity back:

Call c.strange("", (v(LBound(v))))

---

EDIT

Yes, this magic number is a pointer to the VARIANT structure which is supposed to be passed to the strange method. The first field of which is 8, which is vbString, and the data field contains a pointer to the actual string "a".

Therefore, it is definitely a compiler bug… Yet another VB compiler bug in regard of arrays 😉