Bitten by VAL, it's not my girlfriends name. Watch out.

[doppler]

What I am about to say, is normal in QB45.  <------
In a=VAL(A$) example.  The variable 'a' becomes the numerical representation of A$.  Conversion using VAL converts until a non-numeric value is encountered.  This is unless prefixed by &x.  X being some base like hex (&H).  My high school days I was taught 0-9 are numerical.  A-F are accepted for hex.  Keeping that in mind, what do the following conversions output ?

5555
5 5 5 5
5555G4444
5 5 5 5 G 4 4 4 4
&H15B3

If you say 5555 you are right!!  Now the gotcha.  Why is space considered a numeric ?  A leading space yes, to determine negative or positive numbers.  But space in between all numbers.  Give me a break.  Even Wikipedia gave a non-answer answer (best I could find).

[FellippeHeitor]

What to do?
😂

Thanks for checking first with our "mother language" - that'd have been my first impulse too.

[doppler]

I thinks it's just a programming thing they did to handle spaces on prefix.  Made space an exception value, (ignored).  And kept going.  I could use right trim, but in my case I am string searching before conversion.  Wouldn't work.

[Pete]

VAL returns results for space, but also tab, chr$(9), the plus and minus keys, and the decimal point. Have a look at the code and run it to see the info above highlighted on the screen of all 256 ascii characters.

Code: QB64: [Select]

1. WIDTH 160, 43
2. _SCREENMOVE 0, 0
3. _CONTROLCHR OFF
4. xx% = 2
5. FOR i = 0 TO 255
6.     j = j + 1
7.     a$ = CHR$(i)
8.     LOCATE j, xx%
9.     i$ = SPACE$(3)
10.     x$ = LTRIM$(STR$(i))
11.     MID$(i$, 4 - LEN(i$)) = x$
12.     IF VAL(a$ + CHR$(32) + "5") THEN COLOR 14, 4 ELSE COLOR 7, 0
13.     PRINT i$; " Num:"; VAL(a$ + CHR$(32) + "5"); "  Str: "; a$ + CHR$(32) + "5";
14.     IF (i + 1) MOD 43 = 0 THEN xx% = xx% + 27: j = 0
15. NEXT
16. SLEEP

So here's a fun one...

Code: QB64: [Select]

1. PRINT VAL("1" + CHR$(9) + "2" + CHR$(32) + "3")

Comes out 123, right?

Now we add that plus character, which does show up highlighted in the table...

Code: QB64: [Select]

1. PRINT VAL("1" + CHR$(9) + "2" + CHR$(32) + "3" + CHR$(43) + "4")

Still 123, no 4 displayed. For whatever reason, the code table highlights the plus sign but the simple print with VAL code ignores it. Go figure.

Oh, QBasic and QuickBASIC both had VAL bugs. I think it was the VAL("&") registered as 206 or 208, or something like that, and there was a difference in QBAsic and QB54. PDS had fixed this issue. Using the bugs, we could determine which version of QB a user had, QBasic, QuickBASIC, or PDS, using this bug evaluation.

Pete

[doppler]

Now I wish I had a girlfriend named "Val".  I could get her to bite me, it would have been better than this bug.  This VAL feature cost me a 1/4 day of investigation.  Only shown it's ugly head after much investigation in dataset combos.  I can't control the datasets, but I can pretest before VAL is used at the critical point.  Minor slow down.  Only a short scan to find the first non-numeric.  Then limit the string val conversion.

Too bad QB64 is shooting for QB45 compatibility.  Even the bugs/quirks.

Maybe a help file change on VAL entry to point out the difference in usage?

Thanks Pete for really emphasizing the quirk of VAL.  It helped only to more solidify my decision for pretest.