Wiki Home

Visual FoxPro Invocation Stack


Namespace: Wiki
What is the sequence used by Visual FoxPro when locating definitions?

All things considered (functions and class definitions), VFP searches :

  1. Internal commands ( if the function is not prefixed with m.) and base classes, then
  2. User-defined class definitions cached in memory in the order they were loaded, so long as the class definitions are still along SET CLASSLIB or SET PROCEDURE, then
  3. If in VFP 8, a collection's default method, for example myCollection(), then
  4. MyArray(n) array memory variable in scope.
  5. Functions and class definitions in the current .PRG, then
  6. Class definitions along SET CLASSLIB, then
  7. Functions and class definitions along SET PROCEDURE, then
  8. Functions and class definitions in the stored procedures of the current SET DATABASE TO, then
  9. Functions and class definitions in the execution chain (call stack), then
  10. Functions named for files bound in the app/exe, then
  11. Functions named for files in the SET DEFAULT (local) directory, then
  12. Functions named for files out along SET PATH.
  13. COM classes in the OLE registry if SET OLEOBJECT is ON.

Example: For UDF-like syntax
If you have a code segment like this, TestCall(..), here's how fox resolves it
  1. TestCall() VFP native function ( if the UDF is not prefixed with m.)
  2. TestCall(n|c) collection's default method <=== NEW VFP 8
  3. TestCall[n] array memory variable in scope.
  4. TestCall() function defined in the local PRG
  5. TestCall() function defined in SET PROCEDURE
  6. TestCall() function defined in current database's stored procedures
  7. TestCall() function defined in calling programs
  8. TestCall.prg bundled in the app/exe
  9. TestCall.exe/app/fxp/prg file located in SET DEFAULT (FXP/PRG sensitive to SET DEVELOPMENT)
  10. TestCall.exe/app/fxp/prg along SET PATH (FXP/PRG sensitive to SET DEVELOPMENT)

Example: For class definitions
Here's how fox resolves class definitions
  1. Internal base classes, then
  2. User-defined class definitions cached in memory in the order they were loaded, so long as the class definitions are still along SET CLASSLIB or SET PROCEDURE, then
  3. Class definitions in the current .PRG, then
  4. Class definitions along SET CLASSLIB, then
  5. Class definitions along SET PROCEDURE, then
  6. Class definitions in the stored procedures of the current SET DATABASE TO, then
  7. Class definitions in the execution chain (call stack), then
  8. COM classes in the OLE registry if SET OLEOBJECT is ON.


Wouldn't this be called the Invocation Path, not Stack ? -- CFK Why so?
I agree with CFK. One thinks of the stack as being comprised of the main program, the next subprogram, etc. I.e. the calling stack. I've never heard of this usage of "stack" that you assign to this topic, and something like "path" or "precedence" seems more conventional.
Funny, I've never heard of "path" referencing or relating to the invocation stack. Type "Invocation Stack" into Google or Copernick and see for yourself: clearly InvocationStack has tons of prior use. Moreover "path" is, in VFP terms, always related to the physical disk, whose search sequence is one component of the InvocationStack. QED.-- Steven Black
I'd call it "search order". However with InvocationStack, I can charge more per hour. Peter Diotte
The first few results turned up by Google are references to the "method invocation stack (or call stack)" and "invocation stack trace" available when an exception is thrown, and which determines where the exception is caught (by travelling up the invocation stack until an appropriate "catch" clause is found). ( such as at here and here and here ). I couldn't find any reference to "invocation stack" that referred to the initial resolving of class instantiation or method location. -- ?wgcs

I thought that any "stack" was something that was dynamically changed and could generally have none or one "entries". What is being talked about here ius basically ordered and fixed, the only 'dynamic' part(s) possibly being in regards to SET CLASSLIB/PROCEDURE and/or 'collection'.
So I don't see this as being a "stack". I'd call it a "call list" or something like that.-- Jim Nelson

I have to agree that a stack should be something you push and pop things on to/off of. However, the TCP protocols are called a stack, for no good reason I can see. -- Michael Wagner [2005.05.17]

The "good reason" is by analogy with a physcial stack. As for Steven calling this an "invocation stack", you keep using that name. I do not think it means what you think it means. "Invocation stack" generally refers to the thing that gets smashed when you overflow a buffer - what's more usually referred to as the CallStack. In any relevant context, I have only ever heard this concept referred to as a "search path", e.g. where a command processor looks when you type stuff, where the DNS resolver looks for unqualified names. It may be called various things, but the one thing it is not is a "stack".

This topic is quite old now, but "search path" doesn't really work in this context since "path" has always had its own distinct meaning in xBase and lots of other languages too, namely the search order of disk folders. Anyway, likely nobody reading this is the least bit confused about what the information above means. I've called this an "invocation stack" for a long time (over a decade now) and those who complain invariably don't have much better suggestions :-) Then there's Call Stack in wikipedia. -- Steven Black

... which also disagrees with your usage. :o) VisualFoxProNameResolution is a better title, and (unlike the current one) actually describes the content of the page.

See also VFP Last Copy Idiom, Create Object, VFP File Search Path, VFPSet Procedure, Visual Foxpro Environment
Contributor: Steven Black (who could be wrong)
Category VFP Functions
( Topic last updated: 2008.07.11 06:12:47 AM )