variables losing value on current file aliased lookup

[Bruce Easton]

Thanks, Ken.

Bruce

On 4/20/10 11:30 AM, ken white wrote:
> confirmed  behavior fp 5.0.14 sco unix
> the values are maintained in version 5.6
>
> --------------------------------------------------
> From: "Bruce Easton" <bruce at stn.com>
> Sent: Tuesday, April 20, 2010 11:18 AM
> To: <filepro-list at lists.celestial.com>
> Subject: variables losing value on current file aliased lookup
>
>> Below I show some code along with comments below that to explain some
>> unexpected runtime results.     (filepro 5.0.14 - Linux)
>> The code is invoked with clerk from the file "control".
>>
>>          Then: exit
>>   3   --------   -   -   -   -   -   -   -   -   -   -   -   -   -   
>> -   -   -   -   -   -   -   -   -  -
>> @menu   If:
>>          Then: declare GLOBAL targdir(20,*)
>>   4   --------   -   -   -   -   -   -   -   -   -   -   -   -   -   
>> -   -   -   -   -   -   -   -   -  -
>>               If:
>>          Then: targdir="/var/www/html/"{getenv("clientdir"){"/"
>>               .
>>               .
>> 150  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   
>> -   -   -   -   -   -   -   -   -  -
>>               If:
>>          Then: lookup getnum = control@  r=("1")   -np
>> 151 --------   -   -   -   -   -   -   -   -   -   -   -   -   -   
>> -   -   -   -   -   -   -   -   -  -
>>               If: not getnum
>>          Then: goto mssngct    'handle unexpected missing/locked ctrl 
>> rec
>> 152 --------   -   -   -   -   -   -   -   -   -   -   -   -   -   
>> -   -   -   -   -   -   -   -   -  -
>>               If:
>>          Then: viewnum=getnum(1); getnum(1)=getnum(1)+"1"; close getnum
>>               .
>>               .
>>
>> The debugger shows that the value of "targdir" is retained until line 
>> 150, and
>> that as soon as the lookup on line 150 is executed (successfully) the 
>> values of
>> "tardir", and other variables, are cleared.    I don't usually use a 
>> file for dual
>> purpose like this, so I just made a new file to use instead of 
>> "control" for
>> holding the one-up number and the problem went away.
>>
>> There are no other triggers in this code - it runs top-down  - all 
>> from @menu.
>> Is this behavior expected?
>>
>> Bruce
>>
>> Bruce Easton
>> STN, Inc.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> http://mailman.celestial.com/mailman/listinfo/filepro-list 
>
>