ERROR 420: Relational operator expected

[Semen Matusovski]

Eric --
I am afraid that Microsoft sends correct releases to Russia only.
VB6 Prof ("Russian ed." - really English + russian Help)

Private Sub Form_Load()
 a$ = "1"
 b$ = "50"
 Result$ = a$ + b$
 MsgBox Result$
End Sub

Result - 150

If to declare as Variant could be another results (but not unexpected, at least, to me)

Private Sub Form_Load()
 Dim a As Variant, b As Variant, Result As Variant
 
 a = 1
 b = 50
 Result = a + b
 MsgBox Result
End Sub

Result is 51 (clear)

Private Sub Form_Load()
 Dim a As Variant, b As Variant, Result As Variant
 
 a = "1"
 b = 50
 Result = a + b
 MsgBox Result
End Sub

Result is also 51. Note - if a is not a digit value, you will get an error (type mismatch).

Private Sub Form_Load()
 Dim a As Variant, b As Variant, Result As Variant
 
 a = "1"
 b = "50"
 Result = a + b
 MsgBox Result
End Sub

Result is 150 (both are string).

[This message has been edited by Semen Matusovski (edited April 20, 2000).]

[Eric Pearson]

I saw a very surprising (to me, anyway) example of this on a newsgroup recently. The VB program was doing this...

A$ = "1"
B$ = "50"
Result$ = A$ + B$

...and while I would have expected Result$ to contain this string:

"150"

...the actual Result$ was apparently this:

" 51"

Apparently, because the plus-sign was used, VB was really doing this...

Result$ = STR$(VAL(A$)+VAL(B$))

To get the "150" result you'd have to use the & operator instead of +.

I don't know about everybody else, but that type of thing would drive me crazy! I guess you'd get used to it...?

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Tom Hanlin]

On "evil type conversion": Florent's referring to the Visual Basic practice of converting things to variants, so the data types tend to morph on you, and there's extremely loose type checking. With VB, it may be possible to get away with using a string where a number was expected, or vice versa. This can be convenient, although it can also lead to hard-to-find errors, and it imposes a great deal of overhead (read: big and slow).

PowerBASIC employs the safer and more efficient traditional type handling where, if you want to treat a string as a number (or vice versa), you convert the value explicitly with the VAL or STR$ functions.

------------------
Tom Hanlin
PowerBASIC Staff

[Lance Edmonds]

The VAL() function has this functionality (convert hex and binary strings into numerics) built right in:

' Psuedocode
A$ = "01010101"
B$ = HEX$(VAL("&B0" + A$),4)
C& = VAL("&H0" + B$)

...produces "0055" in B$, and 85 in C&

The key here are the prefix's "&B" and "&H" to signify the base of the string representation. I also added a leading 0 to the string to signify that the value is unsigned so you do not get "unexpected" (signed) values if the high-order bit is set.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Thank you both. VAL did the trick. I thought that might be the problem before I posted. I split all the inline args into INTEGER type return values, but it still did not work.

I thought I had read that PB does type conversion? (But maybe not evil type conversion. )

------------------

[Tom Hanlin]

Good call, Florent!

I might also point out that PowerBASIC has an extension to the HEX$ function that allows you to specify how many output digits you want. The result string has zeroes prepended to it as needed to fill it out to the desired length. For example:

  Result$ = HEX$(65, 4)

...produces a result of "0041".


------------------
Tom Hanlin
PowerBASIC Staff

[Florent Heyworth]

Hi Shawn

VB does "evil type conversion" on sBin (STRING) - CINT()
expects a numeric value not a string return. Use VAL() for that kind of thing.

Moreover you'll find that once this problem is corrected that
the compiler will growl when you want to compare "LEN(Bin2Hex) MOD 2" since this is a shortcut for the function return (stack). Better to assign the value to a string variable like "sResult" and return that.

Cheers

Florent

------------------

In converting some functions from VB to PB......

FUNCTION Bin2Hex(BYVAL sBin AS STRING) AS STRING
    DIM i AS INTEGER
    DIM nDec AS LONG
    DIM sLEN as INTEGER

    sBin = STRING$(4 - sLEN MOD 4, "0") & sBin 'Add zero to complete Byte
    sLEN = LEN(sBin)    


    FOR i = 1 TO sLEN
        nDec = nDec + CINT(MID$(sBin, (sLEN - i) + 1, 1)) * 2 ^ (i - 1)
    NEXT i


    Bin2Hex = HEX$(nDec)


    IF LEN(Bin2Hex) MOD 2 = 1 THEN Bin2Hex = "0" & Bin2Hex
END FUNCTION

On the nDec = nDec + ..... line I get the Error 420 Relational operator expected error message. If I run under VB it works fine. I have narrowed it down to be something to do with the MID$.

Any suggestions?



[This message has been edited by Shawn Tartaglia (edited April 19, 2000).]