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