Procedure Execution life

[Elon Close]

Thanks to all of you for the timely informative response. I appreciate
it and the time it took to respond.

Regards, Elon Close

On Jan 20, 2008, at 12:46 PM, David Thompson wrote:

>> 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
> _______________________________________________
> Qna mailing list
> Qna at provue.com
> http://provue.com/mailman/listinfo/qna