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...
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 ;)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With