[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] Document.current



Document.current should be the last Document to have focus. Running code in another file (loadPath, loadPaths) does not change the document that has focus -- and, often the other file isn't open in the GUI, in which case it wouldn't be available to Document.current at all.

Maybe you're looking for thisProcess.nowExecutingPath?

The path saved here is available only synchronously -- that is, any scheduled functions or routines won't have access to it. Probably the best way around that for now is to do this at the top of your file:

var myPath = thisProcess.nowExecutingPath;

Then use myPath wherever you need the pathname.

Yes, I know it would be better if this could be remembered in the scheduler. That's harder than it sounds. It's possible in theory to add an instance variable to Thread (which would also require c++ changes). Scheduling a function is different. The execution context is held in a Frame object, which can be populated only in c++.

Not sure it's really worth it -- I would guess the majority of cases don't need access to the currently executing path in a routine or scheduled function, and when you do need it, it's very simple to take care of it in your code.

hjh



On May 9, 2009, at 2:25 PM, Stephan Wittwer wrote:

Hi,

What is a safe way to get E.G. Document.current.dir from nested calls from different documents?
No problem for one level, but loading something from a doc which in turn is trying to load from another - based on its own current dir - does not work (often? always?). Deferring? AppClock?

How exactly and for what period of time time is an "Document.current" defined?
Sorry for not reading source code.

Thanks, as always. Hope the question is clear.


: H. James Harkins
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman