Quote Originally Posted by Zvoni View Post
Advantage: Less memory used
Disadvantage: Not intuitive for reading code nevermind implicit TypeCast/-Conversion might run havoc and hide Bugs

I wouldn't know of a BIT-DataType.....

The way i would do it:
If you need 14 Booleans (True/False), you would need 14 Bits, which rounds up to 16 Bits, which is 2 Bytes, which corresponds with 2-Byte Integer, and do it via masking
e.g.
The integer-value "3" is binary "0000 0000 0000 0011"
So, to check if Option2 is set you just do a
"If MyOptionInteger And 2 Then Debug.Print "Option2 is True"
Or for Option4
"If MyOptionInteger And 8 Then Debug.Print "Option4 is False"

So, where you take 14/28 Bytes, i take 2
Quote Originally Posted by Elroy View Post
If you really need it dimmed to a million, I'd tend to write some procedures for setting and checking bits. That'd reduce your memory needs by a factor of 8 over Bytes and a factor of 16 over Booleans.

Just as an FYI, Booleans are just a special case of Integers (which are two bytes), although the compiler and the runtime engine try to keep them as either 0 or -1, but not always.

Quote Originally Posted by SmUX2k View Post
Boolean, as mentioned by Elroy, would be 2 bytes per value. 14 values is 28b per, and if you're planning to have 1m of these it'll take up 28MB of memory.

If you chose Byte, it'd be 1 byte per value so that's 14MB.

If, as mentioned, you set up a function that took a value and returned the value of that point (or set the value) you would use about 1.75MB...a fraction of the above. I'm sure you can work out ways to do it with a byte array storing the relative values, it's not too difficult.

If memory is your only requirement (which you haven't specified) the byte array referencing function would definitely perform the best...surprisingly, there are ways in which you could take things even further by compressing the bit data (I had a tree method for compressing weighted bit streams of data that has very few 1s...complicated stuff :-))...it's adding more processing but reducing memory overheads.

If you're looking for speed over memory, I would think byte is best as it's only one byte (rather than two) and takes less time to access...worth testing if you were that worried about the potential speed issues.
Yes, using Bit seems to be the better approach, although it requires more code to be written. I plan to use "Dim BitArray(1) As Byte" to hold 16 Bits. Thanks Zvoni, Elroy and SmUX2k.