Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1776 > unrolled thread

VB6 use of For Each with Collections

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  VB6 use of For Each with Collections stevegdula@yahoo.com - 2013-05-07 14:22 -0700
    Re: VB6 use of For Each with Collections Michael Cole <invalid@microsoft.com> - 2013-05-08 10:21 +1000
    Re: VB6 use of For Each with Collections ralph <nt_consulting@yahoo.com> - 2013-05-07 19:39 -0500
      Re: VB6 use of For Each with Collections Michael Cole <invalid@microsoft.com> - 2013-05-08 11:48 +1000
        Re: VB6 use of For Each with Collections GS <gs@somewhere.net> - 2013-05-07 23:55 -0400
      Re: VB6 use of For Each with Collections Deanna Earley <dee.earley@icode.co.uk> - 2013-05-08 09:19 +0100
        Re: VB6 use of For Each with Collections stevegdula@yahoo.com - 2013-05-08 08:27 -0700
          Re: VB6 use of For Each with Collections ralph <nt_consulting@yahoo.com> - 2013-05-08 11:25 -0500
            Re: VB6 use of For Each with Collections ralph <nt_consulting@yahoo.com> - 2013-05-08 11:52 -0500
              Re: VB6 use of For Each with Collections stevegdula@yahoo.com - 2013-05-08 12:00 -0700
        Re: VB6 use of For Each with Collections "Eduardo" <mm@mm.com> - 2013-06-30 22:48 -0300
          Re: VB6 use of For Each with Collections ralph <nt_consulting@yahoo.com> - 2013-06-30 22:09 -0500
            Re: VB6 use of For Each with Collections Schmidt <ng@vbRichClient.com> - 2013-07-01 07:58 +0200
              Re: VB6 use of For Each with Collections "Eduardo" <mm@mm.com> - 2013-07-01 03:47 -0300
            Re: VB6 use of For Each with Collections "Eduardo" <mm@mm.com> - 2013-07-01 04:08 -0300
          Re: VB6 use of For Each with Collections "Eduardo" <mm@mm.com> - 2013-07-01 04:01 -0300
            Re: VB6 use of For Each with Collections vincent.belaiche@gmail.com (Vincent Belaïche) - 2013-07-05 06:30 +0200
              Re: VB6 use of For Each with Collections "Eduardo" <mm@mm.com> - 2013-07-05 03:31 -0300

#1776 — VB6 use of For Each with Collections

Hi folks,

I am just trying to get my head around using the For Each ... to recurse through a custom Collection object.  This is my first use of these tools.

I can't seem to see a way to derive the "KEY" value assigned to a member of the collection while using the For Each approach.  The Default property of the collection object is the "ITEM" value.

Declared in a module:
Public colObject as New Collection

Form code:
Dim varValue As Variant
Dim strValue As String

'Build simple collection
colObject.Add "myItem01", "myKey01"
colObject.Add "myItem02", "myKey02"
colObject.Add "myItem03", "myKey03"
colObject.Add "myItem04", "myKey04"

For Each varValue In colObject
   'This grabs the [Item] value because it is the default property.
   strValue=CStr(varValue)
Next

I don't see a way to determine the "KEY" value.  Use of the KEY value would help me compare one collection to another collection.  My ultimate goal is to use the speed of "For Each" with collections to quickly compare two large textual datasets for discrepancies.  I want to stay away from connections and dependencies to SQL databases/services, and very much prefer to have a simple 100 kb application perform such a task.

I realize I can enter the KEY value in BOTH the KEY & ITEM entries to get my end result, but it doubles the data size of the collection.

Any insight is appreciated.
Thanks.


~Steve

[toc] | [next] | [standalone]

#1777

stevegdula@yahoo.com explained :
> Hi folks,
>
> I am just trying to get my head around using the For Each ... to recurse 
> through a custom Collection object.  This is my first use of these tools.

You are not using a custom Collection object.  You are using a 
stock-standard out-of-the-box collection, which will contain variants.

> I can't seem to see a way to derive the "KEY" value assigned to a member of 
> the collection while using the For Each approach.  The Default property of 
> the collection object is the "ITEM" value.

It's not the default value, its the only value.  Key is not a property, 
it's a way of retrieving the object.  You cannot access it as a 
property.

> Declared in a module:
> Public colObject as New Collection
>
> Form code:
> Dim varValue As Variant
> Dim strValue As String
>
> 'Build simple collection
> colObject.Add "myItem01", "myKey01"
> colObject.Add "myItem02", "myKey02"
> colObject.Add "myItem03", "myKey03"
> colObject.Add "myItem04", "myKey04"
>
> For Each varValue In colObject
>    'This grabs the [Item] value because it is the default property.
>    strValue=CStr(varValue)

No.  It grabs the collection item, which happens to be a variant 
containing a string.  'Cos a string is what you added to it.

> Next

-- 
Michael Cole

[toc] | [prev] | [next] | [standalone]

#1778

On Tue, 7 May 2013 14:22:36 -0700 (PDT), stevegdula@yahoo.com wrote:


>I can't seem to see a way to derive the "KEY" value assigned to a member 
>of the collection while using the For Each approach.  The Default property 
>of the collection object is the "ITEM" value.
>
> /snipped
>
>I don't see a way to determine the "KEY" value.  Use of the KEY value would
> help me compare one collection to another collection.  
> /snipped
>I realize I can enter the KEY value in BOTH the KEY & ITEM entries to get my end result, but it doubles the data size of the collection.
>

As you discovered, you can't, as there is no "Key" property.

There are various work-arounds using additional arrays or collections,
and mechanisms to combine multiple properties within a single value.

It sounds like you have explored them.

[The Scripting Dictionary is another solution, but would require an
outside reference. Dictionaries do seem a tad faster than VB
Collections.]

The easiest way, and my personal preference, is to create your own
Collection and add a Key property, as per CVMichael's suggestion ...
http://www.vbforums.com/showthread.php?423549-RESOLVED-Displaying-the-quot-Key-quot-in-a-Collection

This has the additional advantage of allowing you to also provide
other useful "Properties" when designing specialized Collections.

However, as noted this will also store a "Key" twice.

If storage is such a problem, perhaps you might explore creating a
Class that manages Arrays and key mappings to mimic a VB Collection.

-ralph

[toc] | [prev] | [next] | [standalone]

#1779

ralph was thinking very hard :
> On Tue, 7 May 2013 14:22:36 -0700 (PDT), stevegdula@yahoo.com wrote:
>
>
>> I can't seem to see a way to derive the "KEY" value assigned to a member 
>> of the collection while using the For Each approach.  The Default property 
>> of the collection object is the "ITEM" value.
>> 
>> /snipped
>> 
>> I don't see a way to determine the "KEY" value.  Use of the KEY value would
>> help me compare one collection to another collection.  
>> /snipped
>> I realize I can enter the KEY value in BOTH the KEY & ITEM entries to get my 
>> end result, but it doubles the data size of the collection.
>> 
>
> As you discovered, you can't, as there is no "Key" property.
>
> There are various work-arounds using additional arrays or collections,
> and mechanisms to combine multiple properties within a single value.
>
> It sounds like you have explored them.
>
> [The Scripting Dictionary is another solution, but would require an
> outside reference. Dictionaries do seem a tad faster than VB
> Collections.]
>
> The easiest way, and my personal preference, is to create your own
> Collection and add a Key property, as per CVMichael's suggestion ...
> http://www.vbforums.com/showthread.php?423549-RESOLVED-Displaying-the-quot-Key-quot-in-a-Collection

Another solution would be to use three standard collections - two for 
holding the datasets, and one for holding the list of dataset field 
names from both.

Then go through the field names collection in sequence, and for every 
field name, compare the items in the two dataset collections.

I can explain this better if it is not clear.

-- 
Michael Cole

[toc] | [prev] | [next] | [standalone]

#1780

> Another solution would be to use three standard collections - two for 
> holding the datasets, and one for holding the list of dataset field 
> names from both.
>
> Then go through the field names collection in sequence, and for every 
> field name, compare the items in the two dataset collections.
>
> I can explain this better if it is not clear.

IMO, it would be easier, then, to use arrays for what you suggest. Why 
bother with the extra code to create/loop collections?

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#1781

On 08/05/2013 01:39, ralph wrote:
> The easiest way, and my personal preference, is to create your own
> Collection and add a Key property, as per CVMichael's suggestion ...
> http://www.vbforums.com/showthread.php?423549-RESOLVED-Displaying-the-quot-Key-quot-in-a-Collection

You don't necessarily require a custom collection class, but you can add 
custom classes that have their "Key" property to a standard collection.

> However, as noted this will also store a "Key" twice.

Note that the key in the collection is normally hashed so only an extra 
few bytes per entry is used.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1782

Deanna ~ thanks for that bit.  I forgot that the Key value is actually ingested into a fixed length hash value.  With that in mind I guess it serves my purpose to use my (textual data string) as both the Key & Item entries in the collection.  If I absolutely need separate Key & Item values, I could use some simple approaches as pointed by by Ralph via his supplied link [ see below ]:

1. Dim MyCollection As New Collection
2. Dim sCollectionData(2)
3. 
4. ''To add elements
5. sCollectionData(1) = sKey
6. sCollectionData(2) = sValue
7. MyCollection.Add sCollectionData, sKey
8.
9. ''To retrieve it
10.       'Retrieve by ordinal
11. sKey = MyCollection(AnyIndex)(1)     ''Key retrieved
12. sValue = MyCollection(AnyIndex)(2)   ''value retrieved
13.
14.       'retrieve by key
15. sKey = MyCollection(AnyKey)(1)     ''Key retrieved
16. sValue = MyCollection(AnyKey)(2)   ''value retrieved

I see methods of accomplishing this with 2 collections, and also as Michael suggested, with 3 collections ( whichever approach provides less time overhead )

Thanks everyone!

~ Steve

[toc] | [prev] | [next] | [standalone]

#1783

On Wed, 8 May 2013 08:27:07 -0700 (PDT), stevegdula@yahoo.com wrote:


>I see methods of accomplishing this with 2 collections, and also as Michael
> suggested, with 3 collections ( whichever approach provides less time overhead )
>

That last part ("less time overhead") can be problematic with a VB
Collection - period.

The VB Collection object is ancient and has never been upgraded. It
has always been, albeit damn convenient, robust, functional, and
simple, a slow performer. It is slower than the Scripting Dictionary
for example. If 'speed' is of primary importance then you are better
off to look elsewhere. Just Google for "VB Collection replacement".

[Here is but one site that might be of interest.
http://www.mvps.org/vbvision/collections.htm
]

-ralph

[toc] | [prev] | [next] | [standalone]

#1784

On Wed, 08 May 2013 11:25:43 -0500, ralph <nt_consulting@yahoo.com>
wrote:

>On Wed, 8 May 2013 08:27:07 -0700 (PDT), stevegdula@yahoo.com wrote:
>
>
>>I see methods of accomplishing this with 2 collections, and also as Michael
>> suggested, with 3 collections ( whichever approach provides less time overhead )
>>

But before you get into too many 'performance' options and comparisons
you might want to digress a bit and take at look at this ...

Premature optimization is the root of all evil -- DonaldKnuth 
http://c2.com/cgi/wiki?PrematureOptimization

Required reading for all programmers.

Like Bruce McKinney quoted - "It doesn't matter how fast it is if it
doesn't work." VB Collections *work*. <g>

-ralph

[toc] | [prev] | [next] | [standalone]

#1785

Thanks Ralph.  I haven't had a chance yet to investigate the alternatives to VB collection replacement but I did quickly read thru the premature optimization reference.  I found it falls in line with my own experiences and it is a tad humorous as well.  My requirement might be considered "Mature Optimization", as I am upgrading my fairly old, well established application, that is still heavily in use today.  I know exactly where the bottlenecks are :-)  It is the size of the datasets, which continue to increase, which is crying out for a speed enchancement.  I have used the [Dictionary Object] within the VBScript environment a number of times and this is where I thought the 'similar' underlying Linked-list / Hash table would benefit me with the VB Collection.

~ Steve

[toc] | [prev] | [next] | [standalone]

#1789

"Deanna Earley" <dee.earley@icode.co.uk> escribió en el mensaje 
news:kmd1r5$c1p$1@speranza.aioe.org...

> Note that the key in the collection is normally hashed so only an extra 
> few bytes per entry is used.

This is strange. For speeding up the read access it's logical to use hashes, 
but still, if the full information of the key is not stored somewhere (to 
check "special cases"), it would be subject to collisions (to different keys 
pointing to the same element). 

[toc] | [prev] | [next] | [standalone]

#1790

On Sun, 30 Jun 2013 22:48:19 -0300, "Eduardo" <mm@mm.com> wrote:

>
>"Deanna Earley" <dee.earley@icode.co.uk> escribió en el mensaje 
>news:kmd1r5$c1p$1@speranza.aioe.org...
>
>> Note that the key in the collection is normally hashed so only an extra 
>> few bytes per entry is used.
>
>This is strange. For speeding up the read access it's logical to use hashes, 
>but still, if the full information of the key is not stored somewhere (to 
>check "special cases"), it would be subject to collisions (to different keys 
>pointing to the same element). 
>

Since an error is thrown with any attempt to add an item with an
existing key, and you can easily add multiple copies of the same
object to a collection - as long as each entry has a different key -
what are these special cases and possible collisions?

-ralph

[toc] | [prev] | [next] | [standalone]

#1791

Am 01.07.2013 05:09, schrieb ralph:

>>> Note that the key in the collection is normally hashed so only an extra
>>> few bytes per entry is used.
>>
>> This is strange. For speeding up the read access it's logical to use hashes,
>> but still, if the full information of the key is not stored somewhere (to
>> check "special cases"), it would be subject to collisions (to different keys
>> pointing to the same element).
>>
>
> Since an error is thrown with any attempt to add an item with an
> existing key, and you can easily add multiple copies of the same
> object to a collection - as long as each entry has a different key -
> what are these special cases and possible collisions?

I think, the second part in Eduardos statement:
    "... pointing to the same element"
is a bit misleading, because what he meant was
probably:

"if the full information of the key is not stored somewhere,
  and the calculated Hash-Values of different Keys collide
  (come out the same - and point to the same HashIndex-Pos),
  then there's no additional criterium, to separate those
  same Entries in the HashTable for a successful Lookup".

Or something along those lines...

Hash-Values are like some sort of CRC32 (but with shorter
BitLength') - and so the collision-probability for String-
Keys (producing the same Hash-Index) is relatively high,
and mechanisms need to be in place, to do safe fallbacks
in these cases. The common (and easiest) approach is, to
just store under the same HashIndex also the colliding
entries, should they happen - and to keep them "unique" and
distinguishable there, we cannot only store the Item under
the given HashValue, but the String-Keys need to be stored
in a "lossless format" as well - to be able to perform the
(then of course smaller) fallback-loop (under the given HashIndex).


Olaf

[toc] | [prev] | [next] | [standalone]

#1792

"Schmidt" <ng@vbRichClient.com> escribió en el mensaje 
news:kqr5rq$jdp$1@speranza.aioe.org...
> Am 01.07.2013 05:09, schrieb ralph:
>
>>>> Note that the key in the collection is normally hashed so only an extra
>>>> few bytes per entry is used.
>>>
>>> This is strange. For speeding up the read access it's logical to use 
>>> hashes,
>>> but still, if the full information of the key is not stored somewhere 
>>> (to
>>> check "special cases"), it would be subject to collisions (to different 
>>> keys
>>> pointing to the same element).
>>>
>>
>> Since an error is thrown with any attempt to add an item with an
>> existing key, and you can easily add multiple copies of the same
>> object to a collection - as long as each entry has a different key -
>> what are these special cases and possible collisions?
>
> I think, the second part in Eduardos statement:
>    "... pointing to the same element"
> is a bit misleading, because what he meant was
> probably:
>
> "if the full information of the key is not stored somewhere,
>  and the calculated Hash-Values of different Keys collide
>  (come out the same - and point to the same HashIndex-Pos),
>  then there's no additional criterium, to separate those
>  same Entries in the HashTable for a successful Lookup".
>
> Or something along those lines...
>
> Hash-Values are like some sort of CRC32 (but with shorter
> BitLength') - and so the collision-probability for String-
> Keys (producing the same Hash-Index) is relatively high,
> and mechanisms need to be in place, to do safe fallbacks
> in these cases. The common (and easiest) approach is, to
> just store under the same HashIndex also the colliding
> entries, should they happen - and to keep them "unique" and
> distinguishable there, we cannot only store the Item under
> the given HashValue, but the String-Keys need to be stored
> in a "lossless format" as well - to be able to perform the
> (then of course smaller) fallback-loop (under the given HashIndex).

Exactly Olaf, that's what I meant to say.

Here there is some reading that may be related to this issue: 
http://epaperpress.com/vbhash/
(in the link "PDF format")

[toc] | [prev] | [next] | [standalone]

#1794

"ralph" <nt_consulting@yahoo.com> escribió en el mensaje 
news:c7s1t85hhfbv0bevjug5rb80i097cfsfu4@4ax.com...
> On Sun, 30 Jun 2013 22:48:19 -0300, "Eduardo" <mm@mm.com> wrote:
>
>>
>>"Deanna Earley" <dee.earley@icode.co.uk> escribió en el mensaje
>>news:kmd1r5$c1p$1@speranza.aioe.org...
>>
>>> Note that the key in the collection is normally hashed so only an extra
>>> few bytes per entry is used.
>>
>>This is strange. For speeding up the read access it's logical to use 
>>hashes,
>>but still, if the full information of the key is not stored somewhere (to
>>check "special cases"), it would be subject to collisions (to different 
>>keys
>>pointing to the same element).
>>
>
> Since an error is thrown with any attempt to add an item with an
> existing key, and you can easily add multiple copies of the same
> object to a collection - as long as each entry has a different key -
> what are these special cases and possible collisions?

I don't know how VB handles keys, but my point is that to do it properly 
(for all cases), it's not possible to do (as I understand it) without 
storing the key in a lossless way somewhere. (see my other posts)

[toc] | [prev] | [next] | [standalone]

#1793

"Eduardo" <mm@mm.com> escribió en el mensaje 
news:kqqn4s$nl7$1@speranza.aioe.org...
>
> "Deanna Earley" <dee.earley@icode.co.uk> escribió en el mensaje 
> news:kmd1r5$c1p$1@speranza.aioe.org...
>
>> Note that the key in the collection is normally hashed so only an extra 
>> few bytes per entry is used.
>
> (to different keys pointing to the same element).

I meant two or more different keys producing the same hash.

In the link https://en.wikipedia.org/wiki/Hash_function there is an image 
illustrating this (the first figure at the top right)

So, to be sure that two "input" keys are the same, it's not enough to 
compare it's hashes, because two different keys can produce the same hash, 
so the key must be stored, perhaps not exactly as it is but compressed in a 
lossless way.

[toc] | [prev] | [next] | [standalone]

#1795

"Eduardo" <mm@mm.com> writes:

> "Eduardo" <mm@mm.com> escribió en el mensaje 
> news:kqqn4s$nl7$1@speranza.aioe.org...
>>
>> "Deanna Earley" <dee.earley@icode.co.uk> escribió en el mensaje 
>> news:kmd1r5$c1p$1@speranza.aioe.org...
>>
>>> Note that the key in the collection is normally hashed so only an extra 
>>> few bytes per entry is used.
>>
>> (to different keys pointing to the same element).
>
> I meant two or more different keys producing the same hash.
>
> In the link https://en.wikipedia.org/wiki/Hash_function there is an image 
> illustrating this (the first figure at the top right)
>
> So, to be sure that two "input" keys are the same, it's not enough to 
> compare it's hashes, because two different keys can produce the same hash, 
> so the key must be stored, perhaps not exactly as it is but compressed in a 
> lossless way.

Just one question: isn't the root cause why you cannot get the key that
you do some "Let" assignment to a Variant object like this:

Dim vElement As Variant, oCollection As Collection
....
Let vElement = oCollection.Item(1)

and not a Set assignment to an Object object like this:

Dim oElement As Object, oCollection As Collection
....
Set oElement = oCollection.Item(1)

I must say that I cannot check the code above because I have not any VB
other than VBScript installed on my WindowsXP machine --- can you
install some VB6 for free ?

I am meaning that when you do the let assignment there is some type cast
which makes you loose some of the information in the indiced object. I
do not know how Collections are implemented, but I fully share what
Eduardo has written: the key needs to be stored somewhere in a lossless
way for a hash table to work.

BR,
  Vincent.

[toc] | [prev] | [next] | [standalone]

#1796

"Vincent "Belaïche"" <vincent.belaiche@gmail.com> escribió en el mensaje 
news:80k3l5632h.fsf@gmail.com...
> "Eduardo" <mm@mm.com> writes:
>
>> "Eduardo" <mm@mm.com> escribió en el mensaje
>> news:kqqn4s$nl7$1@speranza.aioe.org...
>>>
>>> "Deanna Earley" <dee.earley@icode.co.uk> escribió en el mensaje
>>> news:kmd1r5$c1p$1@speranza.aioe.org...
>>>
>>>> Note that the key in the collection is normally hashed so only an extra
>>>> few bytes per entry is used.
>>>
>>> (to different keys pointing to the same element).
>>
>> I meant two or more different keys producing the same hash.
>>
>> In the link https://en.wikipedia.org/wiki/Hash_function there is an image
>> illustrating this (the first figure at the top right)
>>
>> So, to be sure that two "input" keys are the same, it's not enough to
>> compare it's hashes, because two different keys can produce the same 
>> hash,
>> so the key must be stored, perhaps not exactly as it is but compressed in 
>> a
>> lossless way.
>
> Just one question: isn't the root cause why you cannot get the key that
> you do some "Let" assignment to a Variant object like this:

I'm not having any problem, I just commented about something that Deanna 
said.

Who was having a problem (a month ago or so) was the one who started the 
thread.

The problem was that it's not possible to retrieve the key in a VB standard 
collection.


> Dim vElement As Variant, oCollection As Collection
> ....
> Let vElement = oCollection.Item(1)
>
> and not a Set assignment to an Object object like this:
>
> Dim oElement As Object, oCollection As Collection
> ....
> Set oElement = oCollection.Item(1)
>
> I must say that I cannot check the code above because I have not any VB
> other than VBScript installed on my WindowsXP machine --- can you
> install some VB6 for free ?

VB6 is not sold any more. It was not free when it was sold (more than 10 
years ago).

> I am meaning that when you do the let assignment there is some type cast
> which makes you loose some of the information in the indiced object. I
> do not know how Collections are implemented, but I fully share what
> Eduardo has written: the key needs to be stored somewhere in a lossless
> way for a hash table to work.
>
> BR,
>  Vincent.
>
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web