Assign class() to object() array

There’s always “just one case” which wrecks it all
Gotta love edge cases :slight_smile:
I’ll just wish you well

You could use plugin functions to check the array: ArrayIsAMBS
Or use GetVariantArrayUboundMBS, GetVariantArrayValueMBS from our plugin to check what’s in an array.

I use that for the memory inspector in my Web Starter Kit, so we can look in any array with an object type.

Thanks Christian. Unfortunately, a plugin can’t be used in this case.

Norman, I’ll post what I find, if I find it. In the meantime, I guess a solution would be to define all the object arrays as Object() and lose type-checking. In this case, that’s not a terrible solution.

What about:

dim o() as Object = v.ObjectValue

If what you’re looking for is serialization, I have a working serialization class for JSON. It works great other than on multi-dimensional arrays. For arrays if the array is of a primitive type then I call a “ConvertToVariantArray” helper method.

v as variant for the input:

[code] dim v2() as Variant
try //Check if implicit cast will work
v2 = v
return v
catch
end

if not v.IsArray then
dim r as new RuntimeException
r.Message = “An Array was not passed to ConvertToVArray method.”
raise r
end

Select Case v.ArrayElementType
case 2//Integer
dim va() as integer = v
for i as integer = 0 to va.Ubound
v2.Append(va(i))
next

case 3//Long
dim va() as integer = v
for i as integer = 0 to va.Ubound
v2.Append(va(i))
next

Continue on for all the primitive types you care about.
[/code]

[quote=132923:@Brock Nash]What about:

dim o() as Object = v.ObjectValue

[/quote]

So unfortunately v.ObjectValue does not work.

Thanks Brock. We already have the primitives handled. As I mentioned, it all works except for the occasional case whose difference is not apparent to me (yet).

[quote=132897:@Kem Tekinay]Thanks Christian. Unfortunately, a plugin can’t be used in this case.

Norman, I’ll post what I find, if I find it. In the meantime, I guess a solution would be to define all the object arrays as Object() and lose type-checking. In this case, that’s not a terrible solution.[/quote]
Ick

Normally, I’d agree, but these classes are meant entirely as a transport so the information within them will be extracted and stored elsewhere.

At any rate, “works” is better than “doesn’t work”. :slight_smile:

implementing an interface
works
subclassable
reliable
can handle ALL data including arrays, dictionaries of arrays, arrays of dictionaries, variants & everything else you throw at it
can correctly deal with deep vs shallow serialization

hence why thats the model we use for all the IDE project saving :slight_smile:

just saying “works right” is better than “myeh close enough” :slight_smile:

I didn’t understand that, but now I get it so I will look into implementing it that way. Thanks.