OldPedant
Mon Jul 07 19:45:00 CDT 2008
> My reference shows that VarType = 10 means vbError. CVErr is not available
> in VBScript, but in VB6 it creates an error object with the number
> specified.
Ummm...I think that technically it does *NOT* create "an error object".
Per the docs:
http://msdn.microsoft.com/en-us/library/aa262707(VS.60).aspx
And I quote:
"Returns a Variant of subtype Error containing an error number specified by
the user."
A Variant is *NOT* an object. It truly is just the fundamental
implementation of a variable. So it's just a block of 16 bytes where the
variant number is a 10 and the value is the given error number. Same as a
block of 16 bytes with a variant number of 3 and a value of 0x00010001 is
seen as a LONG (32-bit integer) with a value of 65537.
And that's the fundamental difference in error handling between VB6 and
VBScript: VBScript really *DOES* use an error *OBJECT*, which is much richer
in implementation than VB6's simple vbError variant.
You *COULD* get a vbError instance in VBScript, by calling a COM component
that returned a VARIANT with the right values in the right spots in the 16
bytes. And I suppose I could even think of instances (VBS calling a COM
component written in VB6) where that might make sense. But of course all
VBScript could do with that variant would be find its VarType and then use
CSTR( ) on it. [I'm pretty sure that VariantChangeTypeEx( ), if asked to
change a vbError variant to a vbString variant would do the same thing the
VB6 does, creating the string
Error NNN
where NNN is the numeric value of the variant.
It's the same principal as having an ADODB.Field object that has a value
that is a decimal variant. VBScript can't handle that particular variant,
but you can call CDBL( ) or CSTR( ) on the value to get it converted to a
variant that VBScript can handle.