Copy link to clipboard
Copied
Dear colleagues,
I am not talking about calling a function from another file for which I used the #include directive. I want to execute a .jsx that I know only at runtime.
Until now I have found this: If a script file contains
#target framemaker
it is possible to use File(lvFilename).execute() (without the target instruction the script would simply open in ESTK).
But: The execute() method triggers a warning that I should execute only scripts from trustworthy sources (or so…).
Is there any other method to execute other scripts? Or is there a way to make my scripts trustworthy?
- Michael
Michael, here's another eval() idea:
var scriptFile = File('/c/Projects/ExtendScript/Alert.jsx');
var script = '#include' + scriptFile.fullName;
eval(script);
I've tried this and it handles nested #includes and $.fileName. I can't be sure that it would work in every situation however. I feel that there must be a more elegant way...
Ian
Copy link to clipboard
Copied
Hi Michael,
You could use the eval() method to do what you need. Here's a simple example that pops up an alert from the Alert.jsx file.
var scriptFile = File('/c/Projects/ExtendScript/Alert.jsx');
var script;
scriptFile.open('r');
script = scriptFile.read();
scriptFile.close();
eval(script);
Caution: some say that eval() is evil, use with care.
regards
Ian
Copy link to clipboard
Copied
Ian,
Thanks a lot for the idea with eval(), but removing the script content from its original location disables features like #include or $.fileName, unless I do some ugly workarounds there.
- Michael
Copy link to clipboard
Copied
Hi Michael,
#include will work with eval() if you use an absolute file path. The best way to do that is to prepend an #includepath directive to the string that is passed to eval();
Ian
Copy link to clipboard
Copied
Michael, here's another eval() idea:
var scriptFile = File('/c/Projects/ExtendScript/Alert.jsx');
var script = '#include' + scriptFile.fullName;
eval(script);
I've tried this and it handles nested #includes and $.fileName. I can't be sure that it would work in every situation however. I feel that there must be a more elegant way...
Ian
Copy link to clipboard
Copied
Hi Michael,
this should also work like this:
CallClient("ScriptingSupport", "[YourPath]\[YourFile].jsx");
I haven't tried it with ES, but in FDK it works well, so I think, it also works with ES in that way.
bye
Markus
Copy link to clipboard
Copied
Am 14.08.2011 um 20:38 schrieb Wiedenmaier:
this should also work like this:
CallClient("ScriptingSupport", "[YourPath]\[YourFile].jsx");
I haven't tried it with ES, but in FDK it works well, so I think, it also works with ES in that way.
Markus, this looks far better than eval() but unfortunately it does not work.
Well, it would be a recursive call, ScriptingSupport calling itself, which is something different from any other client calling a script.
- Michael
Copy link to clipboard
Copied
Reviving an old thread, as the answers so far did not solve my current related problem.
I have tried to use both methods ( the CallClient suggested by Markus and the 'eval' suggested by Ian ) but in this case they do not seem to work. I am wondering if there is any option at all:
I have a binary script file (jsxbin) to execute from another script. CallClient does not seem to do anything at all and the 'eval' method clearly expects a jsx file, as it gives me an unspecified syntax error when trying to run a jsxbin file. I am using the jsxbin file as that takes care of all the nasty include file hassle and is a self-contained executable. The problem is that I need to run it from another executable script file and the script to be executed is only known at runtime (as in the problem Michael originally indicated).
Any suggestions ? Anyone at Adobe who knows whether this would work at all ?
Jang
Copy link to clipboard
Copied
Hi Jang,
CallClient doesn't work from ExtendScript to ExtendScript, as there is the same FDK Client used for executing different scripts. CallClient works only from one FDK Client to another.
So if you want to use CallClient, you need your own small FDK Client, which controls the external script and your script.
AFAIK it's not possible to use eval for jsxbin files.
If the external jsxbin has a command created to execute that function, you can crawl for the command name and execute it with the fcode.
Hope this helps
Markus
Copy link to clipboard
Copied
Hi Michael,
for me, it works with:
$.evalFile("pathToMyFile/myfile.jsxbin")
Copy link to clipboard
Copied
I don't know if this will work for your needs, but it did work for mine…
use "doscript"
app.doScript ("script.jsx");
Copy link to clipboard
Copied
There is no doScript () method on the FrameMaker app object.
Copy link to clipboard
Copied
> Is there a way to make my scripts trustworthy?
Try putting your scripts in your Documents/Adobe Scripts folder.
p.18 of the Javascript Tools Guide has this to say:
On first launch, the Toolkit creates a folder named Adobe Scripts in the user's Documents folder. The
Default favorite in the Scripts panel displays the contents of this folder.
When double-clicking a JSX file, the Toolkit normally acts as an invisible security filter. Before actually
launching the file, a security dialog asks if it is OK to execute the script. The Toolkit treats the user's
Documents/Adobe Scripts folder, however, as a trusted location; when you double-click a JSX file in that
folder, the Toolkit does not display the security alert.
In WIndows, that is "%userprofile%\Documents\Adobe Scripts".
(Taken from a reply of mine at https://forums.adobe.com/message/7080599#7080599)
Copy link to clipboard
Copied
Simply do the following:
var myFile = File('C:/Scripts Panel/scriptFileName.jsx'); // add file location
app.doScript(myFile);
Copy link to clipboard
Copied
There is no "doScript" in FrameMaker.
The best way to do it is to simply do:
$.evalFile('/full/path/to/file.jsx');
If the evalFile is called inside another function, any global scope vars in the target script will actually be in the calling functions scope.
This has the huge advantage that the garbage collecter will free all of those vars once the calling function exits, so the global scope doesn't get filled with junk, nor does it run the risk of name conflicts.
Another (more complicated) option is to use an ExtendScript implementation of require.js (can be found with a bit of googling). This would allow the use of CommonJS modules (like in Node.js).