Long variable name losing value

Barry Wiseman bwiseman at optonline.net
Fri Feb 15 17:29:04 PST 2008



Bruce Easton wrote:
> Barry Wiseman wrote Friday, February 15, 2008 6:47 PM:
> 
>> Bruce Easton wrote:
>>> 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):
>>>
>>>   1  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>>          If:
>>>        Then: exit
>>>   2  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>> @menu    If:
>>>        Then:
>>>   3  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>>          If:
>>>        Then: declare GLOBAL log_name(14,*)
>>>   4  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>>          If:
>>>        Then: '
>>>   5  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>>          If: '[this is the ONLY called table (no chained tables)]
>>>        Then: CALL "setup"      '[setup does not reference "log_name"]
>>>   6  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>> .
>>> .            '[debugger here shows log_name has a value]
>>> 158  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>> process  If:
>>>        Then: 'process file
>>> 159  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>> .     [there are a couple of sys commands in here that are running
>>> .      to completion OK]
>>> 233  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>>          If:  '[debugger shows log_name is blank and so is new(323)]
>>>        Then: new(323)=log_name
>>> 234  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>> .     [there is an import here that is successfully assigning
>>> .      to other 'new' fields]
>>> 375  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>> enndd    If:  '[the record is being created, all but field new(323)]
>>>        Then: close new                         '[populated OK]
>>> 376  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>>
>>>
>>> To get around this, I have assigned a field ln(14,*)=log_name up
>>> on line 4, then below that I now only assign 'new(323)' from ln.
>>> Field new(323) is now getting its value OK this way.
>>> Does anyone know why the long variable could lose its
>>> value?
>> Probably due to something that happens on lines 7-232. :-)
>>
> :):) That's exactly what I might have written had someone 
> posted an example like this.  I was very careful to check 
> all labels and refs to the variable, but I'll try to provide 
> more code and info in another post.  I am showing all refs 
> to "log_name."  
> 
> Bruce

I'm sure there are no intervening references to the variable, but 
nevertheless some intervening *event* is at issue.  Does the value go 
away following a CALL?  Following a SYSTEM command?  Following a popup?


More information about the Filepro-list mailing list