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