I hate the fact you can't specifically cast variable to specific types explicitly. I have run into the same problem with one of my scripts and it all comes down to the way VBscript guesses what you need, instead of doing what you tell it to.
another example>
a = "1,2,3,4"
b = "2,3,4,5"
c = split(a,",")
d = split(b,",")
e = c(2) + d(1)
In some cases like above you get an error, despite the fact it should work, but if you do:
e = Cint(c(2)) + Cint(d(1))
you may end up with 3, instead of 6, because the scripting engine gets confused, decides that d(1) is a string and returns 0 or something...
So some rules of thumb (in theory)>
1. If you don't yet have a value to put in a variable to start with, don't try to use cLng(0) or the like to cast it. VBscript will prabably return a long, but realizing that it will fit into a regular integer, will cast the variable to fit the value itself, not the type you intended.
2. Don't use stuff like a = 1 or a = "Hello", etc. without first using dim a. For some reason plugins won't let you do this, even though it is perfectly valid and will work correctly in a normal script. (Is this something resulting from the way you did the plugins Nick?)
3. If you need to use an element in an array, use a temporary variable to store the value for calculations, so it won't get ignored.
4. Also with arrays. A split array is 'apparently' somehow different than one that has been defined directly, thus you can't expand or contract it with 'redim preserve <array>(new size)'. It will resize (maybe), but does not preserve the contents of the array as it should. This means if you need to do such a thing, you literally have to make a new array that is the same size, copy the split array into it, then resize the temporary one. It is generally easier to
avoid this completely 'if possible'.
There may be other quirks as well, but these are the ones I have run into. Almost makes one wish there was an alternative version of basic that ran as a COM based script language. :p |