DECLARE GLOBAL / EXTERN

[Nancy Palmquist]

Shane Gray wrote:
>  
> 
> Nancy said:
> 
>>I can say this logic works well.  In a programming setup where I was 
>>using a large set of library processes that would be called from 
>>multiple filepro files, I found I could manage it best if I 
>>put all the 
>>declare globals in a called library table.
>>
>>Then each file that does a call does the call to declare the global 
>>variables first, then does the library calls required.
>>
>>Then I only had the variable definitions in one process table 
>>and could 
>>change edits or lengths without updating 20+ tables.
>>
>>I usually did this step in @once to insure that it was done before 
>>anything else and it was always done.
>>
>>I also found that I like to keep the DECLARE's in the table 
>>that needs 
>>them.  So the call table would have the list of DECLARE 
>>EXTERN's that it 
>>needed at the top and not a cut&paste list that included a 
>>lot of other 
>>stuff.
>>
> 
> 
> The only problem with this approach is that you cannot see the variables in
> the F6/D/L list in your current program.  We have also run into problems
> with chained programs (from before call was available) and declare globals
> where because the programs are completely independent the variables would
> need to be declared global in both, or in auto processing.
> 
> We therefore use "declare extern" for called routine parameters in both the
> calling program and the called routine.  Where a specific variable
> length/edit type is required within a called routine, a local variable of
> the required length/edit is used.
> 
> Shane.
> 

Shane,

My process does all those things.  At least 5 chains are used in the 
processing and 15 call tables.  If the global variables have been set 
prior to loading the CHAIN table, the variables are passed to the CHAIN.

input table - calls to "global" table in @once processing.
DECLARE GLOBAL WHOAMI(15,,g)
return to input
DECLARE EXTERN whoami
call "login" table
DECLARE EXTERN whoami
Ask who the heck you are and assign to WHOAMI -
Return to input
call "authorized" table
DECLARE EXTERN whoami
Get a list of functions you may do and log your access request.
return to input
CHAIN to another table
DECLARE EXTERN whoami
I will still know who I am in this table.
RETURN to input
I will still know who I am.
call SOME OTHER TABLE
I will still know who I am.
Return to input

I have DECLARE EXTERN whoami in my auto table but I am not sure it is 
not left over from when I was trying to get this all smoothed out.  I do 
not think it is necessary to make it all work.

I found that it required the whoami(15,,g) the global here and the 
DECLARE GLOBAL to make it work.  I put DECLARE EXTERN in each table that 
needs to know the whoami value.

Each table that uses the WHOAMI variable will list the variable in the 
Variable list.  Unfortunatly, just a declare is not enough to add it to 
the local list.  (BIG WISH LIST ITEM - make this interaction more robust.)

Nancy







> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 


-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com