David Epstein wrote:
I am trying to understand under what conditions Metacard 2.5 can find a
stack that is called without its path, i.e., by a "go stack <shortName>"
command.  My tentative and incomplete list is below, but I wondered if the
full rule set is explained somewhere.

There is this from the 2.7 change log:

***
Stack Loading Overhaul
~~~~~~~~~~~~~~~~~~~~~~

The order of and places where stacks are searched for on the filing system has been updated. Upon attempting to load a stack with filename <filename>, the engine
attempts to open files in the following order:
  1) Attempts to open a file <filename>
  3) Attempts to open a file <current_dir>/<leaf>
  4) Attempts to open a file <startup_dir>/<leaf>
  5) Attempts to open a file <engine_dir>/<leaf>
  6) Attempts to open a file <mc_path_i>/<leaf>
  7) Attempts to open a file <path_i>/<leaf>
  8) Attempts to open a file <home_dir>/<leaf>
  9) Attempts to open a file <home_dir>/stacks/<leaf>
  10) Attempts to open a file <home_dir>/components/<leaf>
Where
  <current_dir> is the current working directory (i.e. the value of
'the folder')
  <startup_dir> is the directory that was current at the time the
engine was started up
  <engine_dir> is the directory containing the engine executable
  <mc_path_i> is the i'th path present in the MCPATH environment variable
  <path_i> is the i'th path present in the PATH environment variable
  <home_dir> is the value of the HOME directory
If any paths depend on an environment variable that doesn't exist, that
step is skipped.
***

A related question:  Is it good practice to use the file extension ".mc" or
".rev" in a "go stack <shortName>" command?

It doesn't matter which one you use, or whether you use one at all. The engine doesn't look at the extension when determining if the file is a stack, it looks at the internal file structure.

--
Jacqueline Landman Gay         |     [EMAIL PROTECTED]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Reply via email to