Assignments to uncast dummy fields (was Re: simple comparison failing)
Tyler
tyler.style at gmail.com
Fri Feb 15 08:56:12 PST 2008
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):
>
> > Odd...my reply to Ken cc'd the list. I wonder why it showed up so late?
> >
> > 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.
>
> > r is initially assigned an empty string: r="". Later on it happens to
> > have (in this case) a zero plunked in it.
>
> I assume the zero came from a (1,.0) field, and not a literal "0"?
>
> [...]
>
> Try the following:
>
> ::end:
> @entsel::show "\{T}-test assign to uncast field":
> ::end:
> @keyt::xx:
> ::xx = "foo" ; gosub showit:
> ::xx = @t4 ; gosub showit:
> ::xx = "1"/"2" ; gosub showit:
> ::end:
> showit::mesgbox "'" & xx & "'\n(" { @len(xx) { "," { @edit(xx) { ")":
> ::return:
>
> --
> KenBrody at BestWeb dot net spamtrap: <g8ymh8uf001 at sneakemail.com>
> http://www.hvcomputer.com
> http://www.fileProPlus.com
>
Hmmm...how does filePro decide if xx="0" is meant as a string or a
numeric? It could be either, depending on the context you use it in
later. What about things like "00019", where you would want to keep
the leading zero? Wouldn't it make more sense to have all undefined
variables be of edit * than automagically assigning them an edit type?
Tyler
More information about the Filepro-list
mailing list