[RESOLVED] Val(True) = 0. Why?

We all know that in vb6, boolean values are True = -1 and false = 0.

But if you wrap a boolean value in a Val function, it always returns 0, whatever it's original value.

Val(-1) = -1.

Val(True) = 0.

That can't be right.

(Okay, you might ask why I'm wrapping a boolean in a Val function; it's a long story which I won't go into now as it's besides the point).

Quote:

---

Originally Posted by simonm

We all know that in vb6, boolean values are True = -1 and false = 0.

But if you wrap a boolean value in a Val function, it always returns 0, whatever it's original value.

Val(-1) = -1.

Val(True) = 0.

That can't be right.

---

The Val function accepts a *string* as input. So the following calls are equivalent:

Code:

---

?Val(True)
?Val(CStr(True))
?Val("True")

---

Since there aren't any digits in the string "True", zero is returned and that's correct.

HTH,
Wolfgang

easy ;)

val takes a string, so the boolean is first cast to string and then passed to val. val("true") is zero

you can use -cInt(True)

Okay, that explains it.

Thanks.

The Val() function should be avoided anyway. It is obsolete and has side-effects that can be harmful unless you intentionally want these side effects.

It is almost always better to use one of the "grown up" conversion functions such as CLng(), CInt(), etc. that were meant to replace crusty old and slow Val(), which is really only in VB6 at all to make it easier to port old MS Basic code to VB6.

The advantage of Val() though is that you can chuck anything at it (nearly) and get a number at the end without errors, even NULLs. In my case, I had a variant. A limitation with VB6 is you have no TryCast() functions (although there is an IsNumeric() function).

Quote:

---

Originally Posted by dilettante

The Val() function should be avoided anyway. It is obsolete and has side-effects that can be harmful unless you intentionally want these side effects.

It is almost always better to use one of the "grown up" conversion functions such as CLng(), CInt(), etc. that were meant to replace crusty old and slow Val(), which is really only in VB6 at all to make it easier to port old MS Basic code to VB6.

---

The other numeric conversion methods are all locale aware.
I need to deal with a lot of text based data files in which numeric values are stored in the "US" format, that is with a decimal point.
So I always use Val() function to parse these values.
I wrote my own CStrVal() funtion which is also locale aware to write numeric values in these data files.

Quote:

---

Originally Posted by Arnoutdv

The other numeric conversion methods are all locale aware.

---

Yes, and this is the side effect of Val() and Str$() that can be useful at times. However you don't reach for these functions first, they're a last resort if you want locale-blind conversions.

People should not get into the bad habit of defaulting to these functions for general use.