Yes that was a very silly mistake of mine.
Your way does work on InDesign (all versions maybe since CS5)
Any string will do for the name
So for my CSTK I'll use
<ScriptPath Engine="CSTK"></ScriptPath>
I use my JSX.js to load the scripts so I can just leave the path blank.
On Illustrator it didn't do anything (that I could see) Vers 2017, 2018
Don't see a big difference between the <ScriptPath Engine="CSTK"></ScriptPath> and #targetengine CSTK
One point that if one runs a script at least from the ESTK on Illustrator you can choose between transient and main using #targetengine but not Engine
Trevorׅ wrote Don't see a big difference between the <ScriptPath Engine="CSTK"></ScriptPath> and #targetengine CSTK One point that if one runs a script at least from the ESTK on Illustrator you can choose between transient and main using #targetengine but not Engine |
Awesome. Thanks very much for the help in figuring this out! I'd mark yours the correct answer but I think it might confuse people without the context of several posts. I'll sum up below.
The original question asked for clarification of the <ScriptEngine> element's Engine attribute's sparse documentation. Specifically:
This defines an optional ID for the ExtendsScript engine. This can be used to run different scripts in the same engine. This value is localizable.
|
What does that mean, exactly? How can it be used?
First, a definition. All ExtendScript script are run inside a specific context (or environment). Each context provides access to defined variables and functions and can have new variables and functions defined. Adobe calls these contexts "engines". Most ExtendScript-supporting Adobe applications support a single engine, running all scripts from panels (including Adobe's own) in the same context. This is why Adobe starts the JavaScript variables section of the JavaScript Tools Guide CC documentation with this:
JavaScript variables Scripting shares a global environment, so any script executed at startup can define variables and functions that are available to all scripts. In all cases, variables and functions, once defined by running a script that contains them, persist in subsequent scripts during a given application session. Once the application is quit, all such globally defined variables and functions are cleared. Scripters should be careful about giving variables in scripts unique names, so that a script does not inadvertently reassign global variables intended to persist throughout a session. |
Unfortunately, this documentation does not use the same terminology as most of the rest of the documentation, which refers to these environments as "engines". While the above is true for most applications, some are capable of running several distinct engines side-by-side. If you properly initialize your script properly (whether through preprocessor directives or the <ScriptPath> element's Engine attribute), you can request that the target application* create a separate engine (context/environment) for your script. If you have two separate scripts (or scripts from separate extensions) that reference the same engine name, they can then share their own "private" engine. This may increase safety (less likely to overwrite someone else's script state/have someone else overwrite your script state), but may also increase difficulty when attempting to share state between scripts.
[* According to the documentation, the only applications that support the ability to run scripts in custom "engines" are Illustrator and InDesign. The documentation is extremely out of date, however: Trevorׅ's attempt to use the feature in recent versions of Illustrator (2017/2018), for instance, did not appear to do anything, although InDesign appears to continue to respect the setting.]
Hopefully others find this a useful addendum to the documentation.
AdChoices