Assignments to uncast dummy fields (was Re: simple comparison failing)

[Kenneth Brody]

Quoting Tyler (Fri, 15 Feb 2008 09:56:12 -0700):

> On Fri, Feb 15, 2008 at 9:11 AM, Kenneth Brody <kenbrody at bestweb.net> wrote:
>> Quoting Tyler (Fri, 15 Feb 2008 08:36:28 -0700):
[...]
>>  > Anyway, 'r' is undefined.  It doesn't have a type, numeric or
>>  > otherwise.  So where is ".0" coming from?
>>
>>   From the value you assigned to it.  If you have something like "r = xx"
>>  and xx is a (1,.0) field, then r is now a (1,.0) field.
[...]
> Hmmm...how does filePro decide if xx="0" is meant as a string or a
> numeric?

"0" is a literal string, and is therefore (1,*).

> It could be either, depending on the context you use it in
> later.

No, "0" is a literal string.  Now, if you put it into a numeric field,
then the _field_ is numeric, but "0" is still a literal string of type
(1,*).

>  What about things like "00019", where you would want to keep
> the leading zero?

The literal "00019" is of type (5,*) and will always have leading zeros.
If you want to put it into a field, and still keep the leading zeros,
then don't put it into a field which would remove them.

> Wouldn't it make more sense to have all undefined
> variables be of edit * than automagically assigning them an edit type?

Not to me.  Such fields take on the length and type of whatever you store
in them, which was the point of not giving them an explicit length and
type in the first place.

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