Announcement

Collapse
No announcement yet.

ERROR 420: Relational operator expected

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    Semen Matusovski
    Member

  • Semen Matusovski
    replied
    Eric --
    I am afraid that Microsoft sends correct releases to Russia only.
    VB6 Prof ("Russian ed." - really English + russian Help)
    Code:
    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)
    Code:
    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).]

    Leave a comment:

  • Eric Pearson
    Member

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

    Code:
    A$ = "1"
    B$ = "50"
    Result$ = A$ + B$
    ...and while I would have expected Result$ to contain this string:

    Code:
    "150"
    ...the actual Result$ was apparently this:

    Code:
    " 51"
    Apparently, because the plus-sign was used, VB was really doing this...

    Code:
    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>

    Leave a comment:

  • Tom Hanlin
    Member

  • Tom Hanlin
    replied
    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

    Leave a comment:

  • Lance Edmonds
    Member

  • Lance Edmonds
    replied
    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>

    Leave a comment:

  • Guest
    Guest

  • Shawn Tartaglia
    Guest replied
    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. )

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

    Leave a comment:

  • Tom Hanlin
    Member

  • Tom Hanlin
    replied
    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:
    Code:
      Result$ = HEX$(65, 4)
    ...produces a result of "0041".


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

    Leave a comment:

  • Florent Heyworth
    Member

  • Florent Heyworth
    replied
    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

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

    Leave a comment:

  • Guest
    Guest

  • Shawn Tartaglia
    Guest started a topic ERROR 420: Relational operator expected

    ERROR 420: Relational operator expected

    In converting some functions from VB to PB......
    Code:
    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).]
Working...
X