Long variable name losing value
Bruce Easton
bruce at stn.com
Sat Feb 16 15:45:17 PST 2008
(response inline)
Quoting Kenneth Brody <kenbrody at bestweb.net>:
>
> Quoting Bruce Easton (Fri, 15 Feb 2008 18:17:53 -0500):
>
> > I'm seeing something kooky today where it appears that a long
> > variable is losing its value.
> >
> > Here is not all, but what I hope are the relevant parts of the
> > prc table (runs from clerk - 5.014):
>
> I assume you mean "5.0.14"?
Yes.
>
> [...]
> > Then: declare GLOBAL log_name(14,*)
> [...]
> > . '[debugger here shows log_name has a value]
> [...]
> > If: '[debugger shows log_name is blank and so is new(323)]
> > Then: new(323)=log_name
> [...]
>
> Given the lookup alias "new", can I guess that you have a lookup free
> to
> the current file?
No. That alias new is creating a record in another file. The *only* lookup
to the current file during this @menu process is one that is aliased and
looks successfully to a specific control record. (Maybe my last
post from work last night never made it to the forum where it talked about
where I found the debugger shows the value losing right after the lookup to
the control record #1 of the current file to get a one-up number as
in "ctrl=<current file> r=("1") -np".
But am I right to assume that what was addressed below in mod #783 would also
cover this? Sounds like it.
Bruce
Bruce Easton
STN, Inc.
>
> This is from the 5.0.15 readme:
>
> ==========
> (All) #783
>
> A non-dash lookup to the main file may clear non-",g" DECLAREd
> variables. (See also #785.)
> ==========
>
> --
> KenBrody at BestWeb dot net spamtrap:
More information about the Filepro-list
mailing list