Obtain Collection key in VB6

[Chris]

In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.

I'm well aware that there are lots of ways to accomplish
what I need but I specifically want to use a VB
Collection. I do not want to:
A) Use a Dictionary object.
B) Add a Key property to items.
C) Create a wrapper for the Collection.
D) Use a Collection but store the item as an array of key
& item.

[Robert]

I think there is no way (Someone please tell me it's not true).
What you want or don't want is usually not much of a concern for VB.

Robert

Post by Chris
In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.
I'm well aware that there are lots of ways to accomplish
what I need but I specifically want to use a VB
A) Use a Dictionary object.
B) Add a Key property to items.
C) Create a wrapper for the Collection.
D) Use a Collection but store the item as an array of key
& item.

[Schmidt]

Post by Chris
In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.

You could use a second collection (only for the keys), and take care, to
handle it synchronously for all adds, removes on the original collection.

Olaf

[Jeff Johnson [MVP: VB]]

Post by Chris
In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.
I'm well aware that there are lots of ways to accomplish
what I need but I specifically want to use a VB
A) Use a Dictionary object.
B) Add a Key property to items.
C) Create a wrapper for the Collection.
D) Use a Collection but store the item as an array of key
& item.

You'll spend more time trying to retrieve the Key from the standard
Collection object than you would redesigning your app.

[alpine]

On Wed, 19 May 2004 03:38:24 -0700, "Chris"

Post by Chris
In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.
I'm well aware that there are lots of ways to accomplish
what I need but I specifically want to use a VB
A) Use a Dictionary object.
B) Add a Key property to items.
C) Create a wrapper for the Collection.
D) Use a Collection but store the item as an array of key
& item.

You might want to troll around Eduardo's site. I seem to remember
that he did some work in this area.....
(http://www.mvps.org/emorcillo/)

If you strike out there, you might want to look at the
CSuperCollection project at http://www.mvps.org/vbvision/ You can
create your own collection object with any properties and
functionality you desire.

HTH,
Bryan
____________________________________________________________
New Vision Software "When the going gets weird,"
Bryan Stafford "the weird turn pro."
alpine_don'***@mvps.org Hunter S. Thompson -
Microsoft MVP-Visual Basic Fear and Loathing in LasVegas

[Ken Halter]

Post by Chris
In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.

Adding to the pile here... as Bryan mentioned, Eduardo A. Morcillo
posted a method. It's considered a hack (by some) but imo, a hack that
works every time is no longer a hack <g>

Subject: Re: Retrieve Key from Collection Item
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=eil1JZXbBHA.612%40tkmsftngp03

[songie D]

If you don't want to store the key in the objects, then
you stand little chance of getting it out.
Same as if you don't store the price of fish in the objects,
you have little chance of them telling you that information
either.

Post by Chris
In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.
I'm well aware that there are lots of ways to accomplish
what I need but I specifically want to use a VB
A) Use a Dictionary object.
B) Add a Key property to items.
C) Create a wrapper for the Collection.
D) Use a Collection but store the item as an array of key
& item.

[songie D]

BTW you can easily do this in .NET. Collections provide
an IndexOf method, which takes an object as a parameter
and returns the index of it.

Post by Chris
In VB6, is it possible to obtain the keys of items in a
Collection object? Can it be done using the Win API? I
have many components which use the Collection and I'm
trying to avoid having to change them.
I'm well aware that there are lots of ways to accomplish
what I need but I specifically want to use a VB
A) Use a Dictionary object.
B) Add a Key property to items.
C) Create a wrapper for the Collection.
D) Use a Collection but store the item as an array of key
& item.

[Schmidt]

Post by songie D
BTW you can easily do this in .NET. Collections provide
an IndexOf method, which takes an object as a parameter
and returns the index of it.

Simple enough in VB.Classic:

Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
For Each Itm In Col
IndexOf = IndexOf + 1: If Itm Is Obj Then Exit Function
Next
IndexOf = 0
End Function

Olaf

[songie D]

Yes, with extra code and a fricking loop
That's the whole reason they invented .NET

[Schmidt]

Yes, with extra code and a fricking loop!

Do you really think, the .NET implementation of IndexOf is done without a
loop?

That's the whole reason they invented .NET

You mean, the amount of invention regarding .NET is proportional to the
amount of useless framework-methods; that the main-innovation is the
over-weightiness?

Olaf

[songie D]

Post by Schmidt
Do you really think, the .NET implementation of IndexOf is done without a
loop?

Perhaps not, but *YOU* don't have to bloody write it!

Post by Schmidt
You mean, the amount of invention regarding .NET is proportional to the
amount of useless framework-methods; that the main-innovation is the
over-weightiness?

Well, folk who started out on QBASIC in the '60s and are now
confined to ranting about 'the death of classic VB' and
moaning about how microsoft have 'abandoned the VB religion',
and just sit at home and write 'cool windows utilities'
all day; can maybe claim the downloadability
of the .NET runtime is getting in the way a bit, even if it is only
to hide the fact that they just stubbornly fail to see it their
responsibility
to learn anything new.
But frankly, those of us in commercial environments, just don't
give a toss about that, as we've got what's called a "LAN",
and .NET means we don't have to faff around with stupid ADO versioning
conflicts and the like, and enables us to get on with the actual
job in hand.

Post by Schmidt
Olaf

[Schmidt]

Post by songie D

Post by Schmidt
Do you really think, the .NET implementation of IndexOf is done
without a loop?

Perhaps not, but *YOU* don't have to bloody write it!

Up to a certain degree I follow the idea of preimplemented functionality
inside a Framework/Runtime (call it as you like).
But at some point you are faster, typing some simple procedure yourself,
knowing that the few LOCs will definitely work inside the current context,
instead of studying framework-docu and testing out something simple, that
looks promisingly.

Post by songie D
Well, folk who started out on QBASIC in the '60s and are now
confined to ranting about 'the death of classic VB' and
moaning about how microsoft have 'abandoned the VB religion',
and just sit at home and write 'cool windows utilities'
all day; can maybe claim the downloadability
of the .NET runtime is getting in the way a bit, even if it is only
to hide the fact that they just stubbornly fail to see it their
responsibility to learn anything new.

You can be assured, that many VB.Classic-Developers are holding their eyes
open.
In my case I follow the developement of Mono (nearly fully compatible in the
meantime with ASP.NET and ADO.NET) and I will test the new JRE 1.5 upcoming
soon. I'm looking at the rapidly growing maturity of the
linux-desktop-environment and will jump to a new language in two or three
years - for this period VB.Classic suits all my needs on the
Windows-Platform.
I'm not willing to back the wrong horse again.

Post by songie D
But frankly, those of us in commercial environments, just don't
give a toss about that, as we've got what's called a "LAN",

"LAN", that must be something new, introduced by MS together with the
.NET-Platform - never heard this before.

Post by songie D
and .NET means we don't have to faff around with stupid ADO versioning
conflicts and the like, and enables us to get on with the actual
job in hand.

You mean, you like it better to faff around with stupid versioning conflicts
regarding the entire .NET-runtime?

Olaf

[songie D]

Post by Schmidt
But at some point you are faster, typing some simple procedure yourself,
knowing that the few LOCs will definitely work inside the current context,
instead of studying framework-docu and testing out something simple, that
looks promisingly.

No, it never is. Once you know a framework method and you've tested it
and you know exactly what it does, it will always save you time in the
future.
Using VB6 on the other hand, at the very least, you've got to navigate to
the
folder where your pre-built algorithm is stored (assuming you bothered to
file it away) and integrate it into your project.

Post by Schmidt
In my case I follow the developement of Mono (nearly fully compatible in the
meantime with ASP.NET and ADO.NET) and I will test the new JRE 1.5 upcoming
soon. I'm looking at the rapidly growing maturity of the
linux-desktop-environment and will jump to a new language in two or three
years - for this period VB.Classic suits all my needs on the
Windows-Platform.
I'm not willing to back the wrong horse again.

I'm hardly a fraction as moralistic as that. I couldn't give a damn. I just
like
programming, right now I'll program in whichever of the languages I'm given
the option of using gives me the most satisfaction. In the future, I'll use
whatever anyone wants me for. I've long got bored of this "where's
programming going" debate, I couldn't give a damn what languages are
going to be around in 5 years time.

Post by Schmidt
"LAN", that must be something new, introduced by MS together with the
.NET-Platform - never heard this before.

No? Unfortunate.

Post by Schmidt
You mean, you like it better to faff around with stupid versioning conflicts
regarding the entire .NET-runtime?

You really would have to be stupid to fail to install the dotnet
framework. It's just one .exe for everything and they WANT you
to install it - what can go wrong?... no, on second thoughts, don't
answer that.

[D***@home.com]

On Thu, 20 May 2004 02:06:02 -0700, "songie D"

Yes, with extra code and a fricking loop!
That's the whole reason they invented .NET

Ah Ha!!! I was wondering why they invented .NET...
Now I know....
It gets rid of extra code and fricking loops...
Hmmm... I was wondering just what all was happening in that 20mgb+++ runtime
library...
Must be all those predifined extra code and .NET Loops... ;-<

Have a good day...

Don

[songie D]

Yeah, but... it's far more interesting to make a program
that you *know* is going to be useful, rather than having
(or obviously wanting) to SPEND YOUR OWN TIME
writing these mundane loops and housekeeping algorithms
all in the hope someone downloads what you write.
I'd hate to have to hope someone downloads what I write...
people want my programs yesterday.
Talk about trying to chop down a sodding forest with
a pair of scissors...
I pity you. Ah well.

Post by D***@home.com
On Thu, 20 May 2004 02:06:02 -0700, "songie D"

Yes, with extra code and a fricking loop!
That's the whole reason they invented .NET

Ah Ha!!! I was wondering why they invented .NET...
Now I know....
It gets rid of extra code and fricking loops...
Hmmm... I was wondering just what all was happening in that 20mgb+++ runtime
library...
Must be all those predifined extra code and .NET Loops... ;-<
Have a good day...
Don

[AustinMN]

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
For Each Itm In Col
IndexOf = IndexOf + 1: If Itm Is Obj Then Exit Function
Next
IndexOf = 0
End Function

Obviously you haven't actually tested this.

Austin

[Schmidt]

Post by AustinMN

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
For Each Itm In Col
IndexOf = IndexOf + 1: If Itm Is Obj Then Exit Function
Next
IndexOf = 0
End Function

Obviously you haven't actually tested this.

Context lost?
If one wants a .NET-Pendant, then one should use the VB-collection to store
object-references only.

But ok, here comes your bulletproofed "IndexOf":

Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
If Col Is Nothing Then Exit Function
For Each Itm In Col
IndexOf = IndexOf + 1
If IsObject(Itm) Then If Itm Is Obj Then Exit Function
Next
IndexOf = 0
End Function

Olaf

[songie D]

Silly debugging issues... tut tut tut

Post by Schmidt

Post by AustinMN

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
For Each Itm In Col
IndexOf = IndexOf + 1: If Itm Is Obj Then Exit Function
Next
IndexOf = 0
End Function

Obviously you haven't actually tested this.

Context lost?
If one wants a .NET-Pendant, then one should use the VB-collection to store
object-references only.
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
If Col Is Nothing Then Exit Function
For Each Itm In Col
IndexOf = IndexOf + 1
If IsObject(Itm) Then If Itm Is Obj Then Exit Function
Next
IndexOf = 0
End Function
Olaf

[AustinMN]

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
If Col Is Nothing Then Exit Function
For Each Itm In Col
IndexOf = IndexOf + 1

Hint: the line of code directly above will generate a compile error...

Post by Schmidt
If IsObject(Itm) Then If Itm Is Obj Then Exit Function
Next
IndexOf = 0
End Function
Olaf

Austin

[Bob Butler]

Post by AustinMN

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
If Col Is Nothing Then Exit Function
For Each Itm In Col
IndexOf = IndexOf + 1

Hint: the line of code directly above will generate a compile error...

Not in the VB I use... it's perfectly legal to use the function name as a
variable within the procedure. IMO it's a very bad practice and I'd never
do it because it makes the code confusing, especially to newbies, and
therefore harder to maintain.

[Bob O`Bob]

Post by Bob Butler

Post by AustinMN

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
If Col Is Nothing Then Exit Function
For Each Itm In Col
IndexOf = IndexOf + 1

Hint: the line of code directly above will generate a compile error...

Not in the VB I use... it's perfectly legal to use the function name as a
variable within the procedure. IMO it's a very bad practice and I'd never
do it because it makes the code confusing, especially to newbies, and
therefore harder to maintain.

I agree that it can be confusing, and avoiding it on that basis is good.
But I certainly would not characterize it as "bad practice"

Just consider the declaration line of every function to create yet another
local variable, in this case a Long named "IndexOf"

Once you get used to that idea, a lot of routines otherwise written with
an extraneous local variable can be optimized a bit.


Bob

[Stefan Berglund]

On Wed, 26 May 2004 09:51:14 -0700, Bob O`Bob

Post by Bob O`Bob

Post by Bob Butler

Post by AustinMN

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
If Col Is Nothing Then Exit Function
For Each Itm In Col
IndexOf = IndexOf + 1

Hint: the line of code directly above will generate a compile error...

Not in the VB I use... it's perfectly legal to use the function name as a
variable within the procedure. IMO it's a very bad practice and I'd never
do it because it makes the code confusing, especially to newbies, and
therefore harder to maintain.

I agree that it can be confusing, and avoiding it on that basis is good.
But I certainly would not characterize it as "bad practice"
Just consider the declaration line of every function to create yet another
local variable, in this case a Long named "IndexOf"
Once you get used to that idea, a lot of routines otherwise written with
an extraneous local variable can be optimized a bit.
Bob

AMEN

---
Stefan Berglund
first shift-minus last a t m s n d o t c o m

[AustinMN]

Post by Bob Butler

Post by AustinMN

Post by Schmidt
Function IndexOf(Obj, Col As Collection) As Long
Dim Itm
If Col Is Nothing Then Exit Function
For Each Itm In Col
IndexOf = IndexOf + 1

Hint: the line of code directly above will generate a compile error...

Not in the VB I use... it's perfectly legal to use the function name as a
variable within the procedure. IMO it's a very bad practice and I'd never
do it because it makes the code confusing, especially to newbies, and
therefore harder to maintain.

Yup, me bad. Next time I will test code that I accuse others of not
testing. :(

It is actually atrocious programming practice. If you had a function that
took no arguments, it would simply use the "current value" when you may well
want it to re-enter recursively. I expected an error relating to a missing
argument (which is what would happen if the function re-entered
recursively).

Austin