checkbox = -1

  • Thread starter Thread starter Dwight
  • Start date Start date
D

Dwight

If a windows form checkbox control is checked, shouldn't the following
equal 1 instead of -1 ?

DIM Acndt_ind as integer

Acndt_ind = CInt(chbAcndt_Ind.Checked)


Thanks
 
Visual Basic converts all Boolean values to either -1 (for True) or 0 (for
False). Other .NET languages, including C#, use 1 and 0 instead. Internally,
1 is the correct value. However, Visual Basic expresses True as -1 for historical
reasons.
 
Huh ..... i believe it is exactly the other way around

Other languages show what you expect VB shows what it actually is

<sarcastic modus >
But i understand you ,, VB can`t be right as it is a dummy language where
evrything is made easier for the common people
</sarcastic modus >

:-)

regards

Michel
 
For those who might be interested:

In C and languages derived from C (C++, C# etc.), true and false are defined
as constants with the values 1 and 0 respectively.

In BASIC and languages derived from BASIC (M-BASIC, GW-BASIC, VB, VB.NET
etc.), False (I can't remember off the top of my head if it is a constant or
not) is a signed integral numeric with the value 0 and True is implemented
internally as Not False, the result of which is -1. If I remember rightly,
the seemingly non-intuitive result is due to the fact that the binary
representation of a signed integral numeric with the value 0, say a signed
byte, is 00000000 and with a bitwise Not applied the result is 11111111
which is equates to -1.


Michel Posseth said:
Huh ..... i believe it is exactly the other way around

Other languages show what you expect VB shows what it actually is

<sarcastic modus >
But i understand you ,, VB can`t be right as it is a dummy language
where evrything is made easier for the common people
</sarcastic modus >

:-)

regards

Michel
Click to expand...
 
to be more specific think binary and you see that it is correct

TRUE and FALSE are complements of each other, and FALSE
is zero or 00000000, the complement of FALSE is 11111111
which happens to be negative , so TRUE = -1.

I have once read an article about it ,,, and i remember that it had
something to do with memory and processor cycles
the implementation of true and false this way made Basic at that time more
efficient as concurent languages in the 16-bit CPU/16KB
RAM days.

I started on the luxuery 64kb of the C64 :-) , but okay in the above light
seen you might say it is for historical reassons

regards

Michel Posseth



Michel Posseth said:
Huh ..... i believe it is exactly the other way around

Other languages show what you expect VB shows what it actually is

<sarcastic modus >
But i understand you ,, VB can`t be right as it is a dummy language
where evrything is made easier for the common people
</sarcastic modus >

:-)

regards

Michel
Click to expand...
 
Well a slightly different story but with the same outcome

looks like we read the same articles in the past :-)

Your posting did`t show up when i posted my explanation , otherwise i
wouldn`t have done it cause it exactly explains what i wanted to

regards

Michel
 
Since I'm not one of the Microsoft programmers who designed the .NET Boolean
data type, perhaps I did speak with more confidence that I should have. What
I said was based on the pre-releases of Visual Basic .NET 2002. When they
first came out, Visual Basic did expose Boolean True as 1, not -1. There
was quite a ruckus among existing Visual Basic programmers, who complained
that a lot of their code depended on True being -1. Therefore, Microsoft
altered the way that Visual Basic exposed Boolean True as an Integer.

Because of this, I assumed that all .NET languages actually see True as 1,
but that Visual Basic was changing it at the last second to -1. But you might
also be right; .NET might use -1 internally, and alter the output at the
last second in all other languages.

If the sarcasm was targeted at me, then it was misplaced. I do not think
Visual Basic is a "dummy" language. Rather, it is my primary development
language, and it is a joy to use such a productive language.
 
Hello Tim ,

I did not target the sarcastic mode to anyone in particular and especially
not to you i hope you noticed the :-) below it , the idea was the funny
side of it
( maybe i just have a weird sence of humor ) .

However you toss up a nice question , because what is actually the truth on
the .Net platform ? , i really don`t know it
cause what Stephany and i dug up is knowledge from the past however if it
still stands , is also a guess for me

Who has the e-mail adress of Cameron Beccario or Stephen Weatherford ??

maybe a forum moderator at MS might be so kind to ask this for us to one of
them

regards

Michel Posseth
 
Hello Tim ,

I did not target the sarcastic mode to anyone in particular and especially
not to you i hope you noticed the :-) below it , the idea was the funny
side of it
( maybe i just have a weird sence of humor ) .

However you toss up a nice question , because what is actually the truth on
the .Net platform ? , i really don`t know it
cause what Stephany and i dug up is knowledge from the past however if it
still stands , is also a guess for me
Click to expand...

Tim was correct in his original post. In .NET true converts to 1. VB.NET
does it's weird boolean dance because of the beta2 rollback changes. It
is -1 in vb.net simply to maintain compatability with VB.CLASSIC where TRUE
equated to -1.

To be honest, this should NEVER be an issue if you follow one simple rule -
never rely on the integer value of true and false. The fact is the booleans
are booleans - not integers and shouldn't be treated as such.
 
Since I'm not one of the Microsoft programmers who designed the .NET Boolean
data type, perhaps I did speak with more confidence that I should have. What
I said was based on the pre-releases of Visual Basic .NET 2002. When they
first came out, Visual Basic did expose Boolean True as 1, not -1. There
was quite a ruckus among existing Visual Basic programmers, who complained
that a lot of their code depended on True being -1. Therefore, Microsoft
altered the way that Visual Basic exposed Boolean True as an Integer.

Because of this, I assumed that all .NET languages actually see True as 1,
but that Visual Basic was changing it at the last second to -1. But you might
also be right; .NET might use -1 internally, and alter the output at the
last second in all other languages.

If the sarcasm was targeted at me, then it was misplaced. I do not think
Visual Basic is a "dummy" language. Rather, it is my primary development
language, and it is a joy to use such a productive language.
Click to expand...
Hey Tim,

Out of curiosity, what benefits are there to using the integer equivalents
rather than the actual Boolean values, especially factoring in that it
would make the code that much harder to understand, complicate logical
operations and completely trip up code converters?
 
You can do maths with them.

Consider:

Const Some_Value As Integer = 12345

Dim New_Value as Integer = 23456

If CheckBox1.Checked Then
New_Value = Some_Value
Else
New Value = 0
Endif

Now consider:

Const Some_Value As Integer = 12345

Dim New_Value as Integer = 23456

New_Value = Some_Value * Math.Abs(Convert.ToInt32(CheckBox1.Checked))

Certainly a seemingly rediculous example, but I'm sure you'll get the idea.
 
Well I stand educated.

A bit of curiosity and Lutz Roeder's Reflector shows (in the Boolean
Structure):

Friend Const [False] As Integer = 0
Friend Const [True] As Integer = 1

and that:

Console.WriteLine(Convert.ToInt32(True))
CheckBox1.Checked = True
Console.WriteLine(Convert.ToInt32(CheckBox1.Checked))
Console.WriteLine(Convert.ToBoolean(0))
Console.WriteLine(Convert.ToBoolean(1))
Console.WriteLine(Convert.ToBoolean(-1))

produces:

1
1
False
True
True

so my previous example doesn't need the sign adjustment and becomes:

New_Value = Some_Value * Convert.ToInt32(CheckBox1.Checked)

In addition, Convert.ToBoolean(Int32) is implemented as:

Public Shared Function ToBoolean(ByVal value As Integer) As Boolean
Return (value <> 0)
End Function

which means that there is no bitwise stuff going on under the hood, rather,
it is nothing more than a logical comparison.


Stephany Young said:
You can do maths with them.

Consider:

Const Some_Value As Integer = 12345

Dim New_Value as Integer = 23456

If CheckBox1.Checked Then
New_Value = Some_Value
Else
New Value = 0
Endif

Now consider:

Const Some_Value As Integer = 12345

Dim New_Value as Integer = 23456

New_Value = Some_Value * Math.Abs(Convert.ToInt32(CheckBox1.Checked))

Certainly a seemingly rediculous example, but I'm sure you'll get the
idea.
Click to expand...
 
AFAIK is everything else than zero true, the used value type, the used
length, the used value is not important for that.

It is based on the bit, therefore in my idea every discussion about this is
arbitrary, even AFAIK the high values could be used as boolean (don't mix
this up with 99999).

Cor
 
The only benefit I see is if you really need to interact with some external
system that just can't handle anything other than integer Boolean values.
But even that is not a compelling argument. If you track Boolean data, you
should use a Boolean. If you do have integer values, you can use them in
logical comparison statements as if they were Booleans (zero=False, non-zero=True).
But I find it better to use a full "If (myIntValue <> 0) Then" instead of
just "If myIntValue Then".

I'm in the process of converting a VB6 application to .NET. I found many
routines where the original programmer coded some Boolean values as integers
by mistake. Their stated data types are all Integer, but only the constants
True and False are ever assigned to them. Because I use Option Strict in
..NET, this automatically flags a warning, making them easy to find.
 
Here's an example. I have a program in VB6 that does OLE automation
of Visio(2003). In the process of upgrading it to .Net(2005), with
Option Strict on, I got some errors where I set some of the Visio
variables to True or False. When I took the advised repair, in
almost every case, it converted True or False to a Short integer.

Robin S.
----------------------------------
 
To be honest, this should NEVER be an issue if you follow one simple rule -
never rely on the integer value of true and false. The fact is the booleans
are booleans - not integers and shouldn't be treated as such.
Click to expand...

I agree with this sentiment whole heartedly!

If you are treating a boolean value as a numeric, you should probably
rethink what you are doing!

Just my 2c

Chris
 
Back
Top