Ezhno,
Thank-you for your help. Comments interspersed.
cds
-----Original Message-----
From: Ezhno Cheveyo
> > > 072: BEGIN CASE
> > > 073: CASE ANS MATCHES '0N' & ANS>0
> > > 074: IF MITM<5,ANS>#"" THEN
> > > 075: IF MITM<7,ANS>#"" THEN GOSUB 200 ; IF
>
> Anyhow, the LOCATE command on the appartments, made a match for
> appartment 1 when appartment 1E0 was what was being looked for.
> 1E0 was interpreted as: 1 x 10^0 which meant the same as 1.
LOCATE BY 'AR' or 'DR', right?
(Incidently, the sort algorithm for LOCATE is different from ReTrieve (&
UniQuery's?) BY, BY.DSND or SSELECT, SORT.)
> Years ago: num(" ":1 ) would give 1, now it is true on 10.something.
Yes.
I'm at 10.0.16, HPUV 11i (should have said that up front), and NUM()
ignores spaces.
Is this considered a fix or a correction? I don't recall anything about
it in any release notes.
But, of course, this pgm does not use LOCATE or NUM().
> In the above example I believe that if ANS is a string, the 0 will be
> treated as: "0" (the string zero). In which case it can be compared.
I know of _n_o_ cases where any string that contains any characters
other than "0" through "9" will pass the "ANS MATCHES '0N'" test.
>
> Perhaps you should change the code to:
> ANS += 0 ;* Force it to become a number
> BEGIN CASE
> CASE ANS MATCHES '1N0N' AND ANS >0
but other CASEs checks for non-numeric ANS:
CASE ANS="" ! ANS="END"
CASE ANS="OFF" ! ANS="O"
CASE ANS="?"
CASE ANS="P"
CASE ANS = "PASSWORD"
> '1N0N' will force at least one numerical digit to pass
That prevents the empty string from passing the "MATCHES '0N'" test,
but the empty string fails the "& ANS>0" test, anyway so we're safe
there.
The bottom line is that "ANS MATCHES '0N'" test should never be true if
ANS contains anything other than the chars "0" through "9". Right?
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
