Thanks for the reply.
I have used the ASC() function in different versions of this code, but I find that the issue is not one of which function to use, but the complexity of the logical expression. The expression in my original post has many layers of nested parentheses, and fails to compile, with a syntax error. You can try it, and you'll see what I mean.
By the way, the code I posted originally is not right. The actual test I need to do is as follows (with the ASC() function).
while ((asc(strupr$(I$),1)<>65) or (asc(strupr$(I$),1)<>82)) and (len(i$)>0) and (i<20)
I$ = mid$(I$,2,len(I$)-1)
i=i+1
endwhile
By embedding the zero length test in the while loop, the loop will terminate if the string is composed entirely of undesirable characters and is stripped to zero length. And the iteration count is a wise precaution against executing in the loop infinitely.
This version still fails to compile, but I believe it is syntactically correct. It appears that your compiler is not happy with the use of a comparison expression (=, >, <, <>) in parentheses, perhaps only when used along with boolean operators (AND, OR). If I take the two outermost layers of parentheses off the comparison expressions, like this:
while asc(strupr$(I$),1)<>65 or asc(strupr$(I$),1)<>82 and len(i$)>0 and i<20
the expression compiles, but is incorrect. According to your documentation, comparison operators have precedence over boolean operators in determining order of operations, so "65 or asc(strupr$(I$),1)", "82 and len(i$)" and "0 and i" will evaluate before the remainder of the expression. This is wrong, and if the compiler actually behaves this way, the code will not result in correct operation. With all the parentheses, the expression is syntactically and logically correct, but will not compile.
Are there limits as to the parsing capabilities of your compiler with regard to nested parentheses? Is the documentation with regard to order of operations correct? Have I discovered a compiler bug?
Please assist...
Thanks,
Patrick Kuras