How to get full path of parent script that uses #include

[TᴀW]

Script A has an #include "ScriptB" line.

ScriptB now needs the full path of Script A -- i.e., exactly the info you get from $.fileName if you run that line in Script A.

But the command $.fileName if it appears in Script B returns the path to Script B, not Script A. (I always thought that #include actually causes the contents of the #include statement to be copied over to that location, but this proves that it is not quite so simple.)

Obviously, this path could be assigned to a variable in Script A and then used in Script B. But Script B is a library component, and the whole point is not to have to update the two-dozen Script A's that are calling Script B. So I would rather not have to modify all the Script A's. It would be better if Script B stays an independent module.

So: How to get the full path of Script A, when you're inside Script B, which has been #included in Script A?

For a moment I thought I had found an answer: The first line of the string $.stack is the file name of Script A. But it doesn't include the path, just the file name, so not good enough.

Can anyone help?

Thanks,

Ariel

[Loic.Aigon]

Hi Ariel,

What about ScriptArgs ?

#include "scriptB.jsx"
app.scriptArgs.set("origin", $.fileName );
test();

And in scriptB :

function test()  {
  var origin = app.scriptArgs.isDefined ( "origin" )? app.scriptArgs.get ( "origin" ) : "unknown";
  alert( "Calling script location is :\r"+origin );
}

HTH

Loic

[TᴀW]

Hi Loic!

Not bad, but it still means modifying all the caller scripts, which I wanted to avoid.

Thanks,

Ariel

[Loic.Aigon]

Hi Ariel

from memory you have

app.activeScript which should return the path of the script being exécuted in indesign

but can't remember if that would be script à or b

loic

[Laubender]

Hi Loic,

app.activeScript should work.

If the main script is started from the Scripts panel.

// a-includes-b.jsx
#targetengine uwe
#include "b.jsx"
alert("Alert from a-includes-b.jsx: "+ app.activeScript.name );

// b.jsx;
alert("Alert from b.jsx: "+ app.activeScript.name);

Both alerts will tell: "a-includes-b.jsx".

Regards,
Uwe

[Loic.Aigon]

Hi Uwe,

Yes I just got my hands on my computer to give this a check and it's basically what I was about to say

Loic

[TᴀW]

Thanks Loic. app.activeScript is something I tried, and it caused a silent error.

Uwe, your example works for me, also without the targetengine directive.

But in the actual scripts I've got, this isn't working. Not sure why -- more checking is needed. But for now, it seems to be not completely reliable in all cases.

Ariel

[Laubender]

Hi Ariel,

is your main script started from the Scripts panel?
Or is it perhaps a startup script? I did not test this case…

Is app.activeScript perhaps nested in a deep structure with b ?
Maybe called from a function within a function?

Regards,
Uwe

[TᴀW]

I managed to figure out why this didn't work for me initially. It doesn't work inside a modal dialog:

alert(app.activeScript.name); // Works fine.
w = new Window("dialog");
b = w.add("button", undefined, "Show script name");
b.onClick = function(){app.activeScript.name}; // Fails
w.show();

So back to square one (well, square two -- the discussion has been helpful so far!), because in my case ScriptB is always called from inside a dialog in ScriptA...

Ariel

[TᴀW]

Strange. This does work:

alert(app.activeScript.name);
w = new Window("dialog");
w.add("editText", undefined, app.activeScript.name);
w.show();

So it doesn't work only inside an event function inside a dialog? More checking needed...

[Marc Autret]

Hi Ariel,

From IdExtenso's implementation notes:

When available, the command `app.activeScript` returns a File object which points out to the *main* running script, that is, the one the user has launched--or made automatic among a `startup scripts` folder. Since included files or files executed via $.evalFile() are just subparts of the main program, they are not retrievable from the activeScript property. [...]

By contrast, `$.fileName` reflects (the full path of) the file being now parsed by the interpreter. In a modular project based on multiple includes, `$.fileName` is the way to identify the actual subpart of interest. In addition, `$.fileName` is still reliable in a JSXBIN stream (contrary to `Error.fileName`.)

[Excerpt from: IdExtenso/$$.Env.jsxlib at master · indiscripts/IdExtenso · GitHub]

Now, an additional fact is that app.activeScript is a DOM command which won't work (as many others) from within a ScriptUI modal context. So, in your case, the best idea is to store ScriptA's $.fileName at a location that ScriptB can reach, for example $.setenv(<ScriptA_Key>, $.fileName). This should work in both modular structure (#include) and compiled stream (jsxbin).

Best,

Marc

[Loic.Aigon]

Hi Marc,

From your experience, is there any reason to prefer $.setenv to scriptArgs ?

Loic

[Marc Autret]

Hi Loic,

scriptArgs is DOM-based (it requires app to be available) while $.setenv is a "low level" ExtendScript command.

@+

Marc

[Loic.Aigon]

I see thanks.

[FRIdNGE]

Hi Masters,

Maybe I'm wrong to post my question here but it seems to me similar!!

I've a simple code line script (.jsx) as:

#targetengine "testsession"  
alert(File(app.activeScript.parent.fsName))

I export it to binary and create a new .jsx like this, including the .binary code:

#targetengine "testsession"  
app.doScript("@JSXBIN@ES@2.0@MyBbyBn0ABJCnAEjzFjBjMjFjSjUBfRBEjzEiGjJjMjFCfRBXzGjGjTiOjBjNjFDfXzGjQjBjSjFjOjUEfXzMjBjDjUjJjWjFiTjDjSjJjQjUFfjzDjBjQjQGfffff0DzAHByB");  

The source scripts [.jsx & .jsxbin] give me the result I expect but not the script above!

What's wrong?

Thanks in advance!

Best,

Michel, for FRIdNGE

[Loic.Aigon]

It's likely because of a "scope" issue. when you call doScript you are loading embedded script "scope" so activeScript points towards the container script (teh one using doScript) but not the embedded script.

Also, you can run you embedded script with eval

eval ( tehCode );

But still, not sure your nested code could read activeScript right away. However it should be easy to either sue $.setenv as Marc pointed out or just a global variable (but be careful here as your code is session persistent.

var theScriptPath = app.activeScript;

eval ( code );

//where code looks at global tehScriptPath value.