Re: Differences between VB6 and VB.Net causing problem


"Larry Serflaten" <serflaten@xxxxxxxxxxxxxx> wrote in message news:%23w2QaUVMJHA.4600@xxxxxxxxxxxxxxxxxxxxxxx

<... snipped code ...>

What you are seeing is the converion. Now try the above with -1 instead of
bln, and I can assure you that -1 <> CByte(255)


That is not surprising, you are comparing apples to oranges.
-1 is an Integer and CByte(255) is a Byte, of course -1 <> 255



You seem to have missed the point. You are saying -1 doens't equal 255; yet True does ;)


Put them both in the same type, then compare:


What do you think the If bln = CByte(255) Then does ? Seriosuly I am curious as to why you think that is "appels to oranges" when the rules for the comparison dictate that the boolean is converted to a byte.


bln = CDec(True)


How many times do I have to tell you Decimal, Single and Double are not bitwise types ? You might as well be converting to a String and then demanding that the internal storage is a string "True". You'd still be wrong.

As I showed you a Boolean is 16 bytes. That's a fact you still seem to fail to accept.


Here CByte(255) does not evaluate to True, for obvious reasons.

Wonrg. Your code was "True" converted to a Decimal does not equal a Decimal with the value of 255. I'm beginning to think you don't get what a bitwise type or operation is. Try sticking to bitwise types.

Also
note that True is represented as FFFFFFFF, a 32 bit value even when
the Decimal type can hold more than 32 bits of information.


Really ? Where did you get that one from ? I do a Hex(True) and I get FFFF, which of course is ***16 bits***.
Are you sure you aren't just trying to convinvce yourself it's 32 bit, and hence whereever you see -1 you think it's 32 bit ?

Of course what you are doing is widening a bittable type into a non bittable type, one which is a larger *type*, and hence when the narrowign conversion occurs, as is necessary to call Hex because HEx only accepts bittable types, VB selects the widest bittable , which in VB6 is Long. You cna play that game with any Byte value, convert to Decimal then call Hex because you are in fact implicitly calling byte -> Decimal -> Long -> Hex()




(On a side
note, its not 'all bits set' in the variable's memory...)


Larry, that's not a side not. It's the fundamental of what a bitwise type is. It is 0 or all bits set.


I would propose that since a Byte type cannot represent negative numbers
the VB designers used 255 rather than raising an error.

Why ? Why not 1 ?


It may very well
be a one-off situation they did to add 'ease of use', rather than raise the
overflow error which you'd normally see when trying to stuff -1 into a Byte.



No. It's actually to do with **bitwise** operations. If you have VB.NET you can see it even easier in there because there we have Byte and signed byte (SByte) right up Int64 and UInt64. If you look at them, say a signed byte, you'll see it has the same bitwise value as a non signed byte. The numeric value however is -1 versus 255. But from a *logical* or *bitwsie* aspect, as opposed to a numeric or textual aspect, the value is simply 0 or Not 0.












.