On Dec 21, 2007 5:13 PM, James Harkins <
jamshark70@xxxxxxxxx> wrote:
Currently it *is* nowExecutingPath - right now it's populated **only** when running a file with executeFile. When the file is done, the variable is cleared.
ok, i geddit
This is something we have to define before going further... when the interpreter is idle, what should this variable hold?
nil
Wait... I see what the issue is. I use Instr.loadAll in my startup.rtf file. That method doesn't do anything to set the path for the Instr.
right, because it can't figure out which instr were just loaded.
if we could always know that :
"filename.instrName"
or
"folder.filename.instrName "
or
"folder.subfolder.filename.instrName"
is what is implied by an instr name,
then after loading the stuff in that file, we could interate through all instr in that path
but ...
Anyway, looking more deeply, the only other place that sets the path -- objectAt -- doesn't do it properly. That method gets the result of loading the file and saves it in a variable instr, then assigns the path to the object in that variable. But this variable can hold the only the last Instr created within the file.
ok, now I'm convinced.
the nowExecutingPath method is the best then
and it has benefits for other code elsewhere
as for Document ...
Document.current.path is an unsafe assumption.
thisProcess.interpretCmdLine could set nowExecutingPath with Document.current.path
and unset it if there is a fatal error.
but I don't see the use in that.
for Instr's needs, I just wanted to know where it was loaded from.
big complication:
when the code in a file loads other code in other files.
this is really common in Instr and in various players.
there would have to be a messy call stack.
grrr.
-cx