Assignments to uncast dummy fields (was Re: simple

[Kenneth Brody]

Quoting Bruce Easton (Fri, 15 Feb 2008 15:30:05 -0500):

> Bruce Easton wrote Friday, February 15, 2008 3:11 PM:
> (response inline again)
>> (response inline)
>> Larry S. Weaver Jr. wrote Friday, February 15, 2008 2:30 PM:
[...]
>> > yy(2,.0)="15"
>> > xx=yy{""+"3" gave "153" with a field edit of (3,*)
>> > xx=yy{""-"3" gave "15-3" with a field edit of (4,*)
>> > xx=yy{""*"3" gave "150" with a field edit of (3,*), as did xx=yy{""/"3"
>>
>> It seems in each of the cases above, yy and the last part of
>> the assignment are all treated numerically, prior to
>> appending of strings, that is
>>
>> yy = 15
>> ""+"3" = 3
>> ""-"3" = -3
>> ""*"3" and ""/"3"  = 0,
>>
>> so I'm guessing that filepro assumes the operand ""
>> before the numeric operator is zero.
>> If that's true, then I would think it would not
>> matter if the final result field were text or numeric -
>> since the only (outer-most) operation left to do is "{",
>> and therefore concatenation is expected.
>>
>
> Except that it does matter :):).  With xx set as numeric,
> the results are the same using +,*,/,
> but the result is just "15" when the operator is "-"
> (compared to "15-3" when the result field is text).
[...]

Well, of course the type of the destination matters to what gets put into
the destination field.  It does not matter, however, to what is the result
of the expression.

    yy { ""+"3"   is still the literal "153".
    yy ( ""-"3"   is still the literal "15-3".

However, if xx is numeric, then:

    xx = "153"    results in xx containing "153".

    xx = "15-3"   results in xx containing "15".

    xx = "123 Main Street"     results in xx containing "123".

Just as one would ("should"?) expect.

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com