Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
Earlier I alluded to the fact that JScript arrays are objects but VBScript arrays are not. What's up with that?
It's kind of strange. Consider the properties of a JScript array. A Jscript array is
* one dimensional.
* associative; JScript arrays are indexed by strings. Numeric indices are actually converted to strings internally.
* sparse: arr[1] = 123; arr[1000000] = 456; gives you a two-member array, not a million-member array.
* an object with properties and methods.
Whereas a VBScript array is
* multi-dimensional
* indexed by integer tuples
* dense
* not an object
It is hard to come up with two things that could be more different and yet both called "array".
As you might expect, JScript and VBScript arrays have completely different implementations behind the scenes. A JScript array is basically just a simple extension of the existing JScript expando object infrastructure, which is implemented as a (rather complicated) hash table. A VBScript array is implemented using the SAFEARRAY data structure, which is pretty much just a structure wrapped around a standard "chunk of memory" C-style array.
Since all the COM objects in the world expect VBScript-style arrays and not JScript-style arrays, making JScript interoperate with COM is not always easy. I wrote an object called VBArray into the JScript runtime to translate VBScript-style arrays into JScript arrays, but it is pretty kludgy. And though I wrote some code to go the other way -- to turn JScript arrays into VBScript arrays -- there were just too many thorny issues involving object identity and preservation of information for us to actually turn it on. There weren't exactly a whole lot of users demanding the feature either, so that part of the feature got cut. (If I recall correctly, my colleague Peter Torr wrote some COM code to do that before he came to work at Microsoft. He might still have it lying around.)
Things got even weirder when I wrote the code to interoperate between CLR arrays and JScript .NET arrays, but that's another story.
Recently I investigated a bug in Jscript which was reported on Vista. The scenario was working perfectly
I have the same problem that David Karlton, but the only difference is that my array has two different dimensions.
Here is the example:
<script language="javascript" type="text/javascript">
function Array2D(dim1, dim2)
{
for (var i = 0; i < dim1; ++i)
this[i] = new Array(dim2);
}
this.length = new Array(dim1, dim2);
function LoadPage()
var mat= null;
mat=new Array(5,2);
var name = '30';
var ar = new Array2D(5,2);
ar[0][1] = "Dato1";
ar[0,1]= 10;
ar[1,0]= "Dato2";
ar[1,1]= 20;
ar[2,0]= "Dato3";
ar[2,1]= 30;
ar[3,0]= "Dato4";
ar[3,1]= 40;
ar[4,0]= "Dato5";
ar[4,1]= 50;
for (i=0;i<=4;i++)
ar[i,0]= 'dato'+i;
ar[i,1]= (i+1)*10;
if(ar!=null)
obj=document.getElementById('TestDll');
mat = obj.LoadPage('30',mat); //Here is the problem
</script>
I need to know if is possible to cast the mat array and bidimensional array that that was sent to C# like parameter in LoadPage Function, and How can I do this? I receive an object of type System.__COMObject but I need a type object [,] in C#.
PingBack from http://futureprogramming.com/?p=8
Here's a simple VBScript function that converts single-dimension JScript array to VBArray:
<script language="VBScript">
Function toVBArray (ByRef jsa)
Dim e, i, vba()
i = 0
For Each e In jsa
ReDim Preserve vba(i)
vba(i) = e
i = i + 1
Next
toVBArray = vba
End Function
In fact it can be used on any object, but you will lose property names. It will also skip "gaps" in sparse JScript arrays.
You can call it from either JScript or VBscript functions. You can create similar functions for converting more dimensions into arr(1,2,3,...) style arrays by nesting For Each loops - it will require separate function for each given number of dimensions though.
arr(1)(2)(3) style VBArrays can be created by modifying this function to call itself recursively (number of dimensions of JScript array would have to be provided as additional argument since there's no way to reliably determine it programmaticaly).