How much do you trust the Collection class?

[Elroy]

Donar,

I use collections quite a bit, and I've never had any problems with them.

I set up your code on my computer (Intel i7, Win7-64-bit) and it ran fine, both IDE and compiled.

I'm not really up for tweaking it and trying to reproduce a similar problem. But I do believe I know what happened. We can both agree that the Collection Key must be unique, right? Quote from MSDN:

key
Optional. A unique string expression that specifies a key string that can be used, instead of a positional index, to access a member of the collection.

Yes, I believe that you attempted to add a key that was a duplicate.

You might ask how there's a difference between the IDE and an executable. Well, let's look at a piece of your code...

    ...ChrW(Int(Rnd() * 65535))

Alright, Rnd() is suppose to return the same sequence of numbers, and I believe that it does. And that's true whether it's compiled or not. However, what it returns is an IEEE single. Therefore, when the multiplication is done, it's going to typecast your 65535 to an IEEE single, and then do the multiplication. This is where differences can come in. I'm not entirely certain how the IDE does IEEE math, but I suspect it uses the Floating-Point-Coprocessor that's built into all contemporary CPUs. However, a compiled VB6 program may take certain steps that cause small differences. Most specifically, there's a default "Safe Pentium FDIV Check" that's built into VB6. This was an old floating point bug that was in some old Pentium CPU chips. You can turn this off under "Advanced Optimizations". There are also a couple of other settings which may have slight changes in the way floating point math is done.

Ok, so how does this affect what you're doing? Well, when Rnd() * 65535 results in a number that's very close to an integer, there may be differences between the IDE and compiled. For instance, if the IDE returns 356.9999! and compiled returns 357.0001!, the Int() function will return different values. Therefore, there can be differences.

This would all be easy to check. When you get an error, report your key, and then attempt to use that key to see if the item already exists in the collection. I'll bet that you'll find that it does.

Also, you might say that you're producing a random twelve-byte sequence to serve as the keys, so how can there be a duplicate after only 13367 attempts. I'm also not going to work out the factorials, but what people don't realize is that it's much easier than people think to find duplicates when you're allowing any two to count. For instance, how many people do you think you need to have in a room to have a better than 50/50 chance that two will have the same birthday? The answer is 23 people. If you get 75 people in the room, there's better than a 99.9% chance that two will have the same birthday.

Therefore, I'm thinking the bug has nothing to do with Collections. In fact, technically, if what I'm saying turns out to be correct, there's no bug at all.

Regards,
Elroy

EDIT1: Also, just staring at that Int(Rnd() * 65535) line, you're doing two typecasts in there. One to typecast 65535 from a Long to a Single. And then, after the multiplication is done, Int() is expecting a Double, so the product will then be typecast from a Single to a Double. To make things more precise, you might want to specify 65535 as a Double (65535#). And then, to be a bit more explicit, you may want to force-typecast Rnd() as a Double (CDbl(Rnd())). And also, since: 0<= Rnd() < 1, i.e., Rnd() never returns ONE, but can return ZERO, the constant literal should be 65536, not 65535. So, putting all that together, things would be better if you had: Int(CDbl(Rnd()) * 65536#)

EDIT2: I don't think this is a problem, but it also concerns me that we're using the entire bit-range of Unicode. VB6 uses the UCS-2 subset of UTF-16 Unicode. This is a subset that has only-and-all two byte characters. However, in this UCS-2 subset, the "official" range of characters is covered in hex-codes from &h0001 to &hD7FF. &h0000 is specifically reserved for an end-of-string indicator, and anything from &hD800 to &hFFFF is outside of the UCS-2 range, and is possibly used for characters that are longer than two bytes. I seriously doubt that Collection keys examine the actual Unicode characters (preferring to just treat them as bits), but I'm not absolutely certain about this.