Procedure Execution life

David Thompson dthmpsn1 at uiuc.edu
Sun Jan 20 11:46:11 PST 2008


>In other words Panorama runs the procedure to completion and if the 
>actions
>pertain to the active DB, that DB is not necessarily the one that 
>contains
>the procedure. This is OK with me, but a little unexpected.
>
>It happens to be that this closure of DB1 and DB2 is what I wanted.

Yes. This is true and several procedures that 
take advantage of this fact have been posted on 
this list. A procedure's only connection with the 
database that contains it is just that. The 
database contains it. That would be the database 
you would need to list in the first parameter of 
a FarCall, so that Panorama will know where to 
find it. Once the procedure has loaded and begun 
to run, it no longer has any connection to the 
database where its code is stored. It is only 
concerned with which database is currently active.

When a FarCall is made, the database that was 
active before the FarCall remains active when the 
procedure begins running. A running procedure can 
change which database is active by doing anything 
that puts a window from another database in 
front. This could be a Window or OpenFile command 
that brings a window to the front, or a 
WindowToBack command that sends the current 
window to the back, or a CloseWindow or CloseFile.

Commands and functions that refer to parts of 
databases, without naming the database, are 
referring to the currently active database.  Any 
direct reference to a field refers to a field in 
the active database, whichever database that 
might be. A GoForm, or OpenForm, would refer to a 
form in the active database. The same would be 
true of the data sheet, design sheet, procedures 
and cross tabs. A Call statement will call a 
procedure in the active database. A FarCall would 
be needed to call a procedure in any database 
other than the active one. In some cases that 
will mean that a FarCall is needed to call 
another procedure in the same database that 
contains the running procedure. Local variables 
that are declared by a procedure remain in scope 
as long as that procedure is running, while 
FileGlobal variables will go in and out of scope 
as the procedure makes first one and then another 
database active. If a procedure declares a 
Permanent or FileGlobal variable, the variable 
will belong to the active database. There are 
several wizards that use this feature to create 
permanent variables for databases other than 
themselves.

Dave


More information about the Qna mailing list