Collections of arrays

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm finding that arrays in collections seem to be read-only - their element
values can't be changed. I need to get a sanity check on this please. I wrote
the following little routine to test this out, and to understand better
whether the array itself was put in the collection or just a pointer to the
original array entity (not as clear as with objects, and not addressed in
Help).

Public Sub dummy()
Dim lCollection As New Collection
Dim lArray(1 To 2) As String

lArray(1) = "a"
lArray(2) = "b"
lCollection.Add lArray
lCollection(1)(1) = "c" 'doesn't change value in Collection or
Array
lArray(1) = "d" 'only changes value in Array, not
Collection

End Sub

As you can see from above, if I try to change the value of the array element
in the collection, nothing actually changes; the original "a" value remains.
No error is reported, so I'm not doing anything obviously illegal. Because I
can read the value, my assumption is that I am addressing the element
correctly. If I change the original array, the value in the array changes to
"d", but the value as addressed by the collection remains "a".

I am using a relatively old version of Access (2000, I believe). If this is
old behavior that has changed, please let me know.

Has anyone dealt with this? I'd hate to have to create a class simply to
replace the array so that this behavior would work as expected, but will if
that's the only workaround. (I don't want to remove and replace the array;
hard to get it back in the same position in the collection.)

Thanks,
BnB
 
Some more on this... it appears to be not just arrays, but anything that
isn't an object. I tried simply putting a string in there (according to Help,
ANY data type can be used), but if I actually try to change the string
contents later, it complains, saying "Object Required."

So it looks like I have to add the overhead of encapsulating simple data
types in their own objects for this to work. By the way, the reason I want to
do this is so that I can key the collection items and access them easily
(rather than iterating through an array looking for the entry I want).

Again, if anyone has any other perspective on what's going on here, I'd sure
like to hear it, since it seems contrary to what would be intuitive (or even
what Help suggests -- if true, this is a rather significant omission from the
description of a Collection's behavior). I can't help feeling I'm doing
something wrong.
 
If you're using string keys you can do stuff like this:

TempArray = lCollection("a")
TempArray(2) = "new value"
lCollection.Remove "a"
lCollection.Add TempArray, "a"
 
But if I'm trying to maintain the order of collection elements, won't this
remove something from the middle and add it back to the end?
 
You said in your second post in this thread that
the reason I want to
do this is so that I can key the collection items and access them easily
Click to expand...
so I assumed that the "index order" didn't matter.

One workround would be to maintain an array each of whose elements was
a key to the collection, e.g.

Dim ColIndex As Variant
ColIndex = Array("First", "Second", "Third")

Then you could address the second item in the collection with either
MyCollection("Second")
or
MyCollection(ColIndex(1))

But it might be simpler to bite the bullet and write a little class.
 
Ah yes... as it turns out, I'm using both integer and key indexing. So I
ended up writing a quick wrapper class for strings. Kind of clunky, but
works. Just hope there's not a limit on the number of classes... :)

But you have confirmed for me that the undocumented rather significant
limitation is not just a bad dream I'm having; it's real. Thanks for that.

BnB
 
Back
Top