ExtendScript Debugger for VSCode: Unable to include script references

[Ian Proudfoot]

I have tried to move an old project from the ESTK into VSCode. While it's generally more difficult to set-up a project, once it is working I think that VSCode is a real improvement on the ESTK. However, I need to debug a script that includes other scripts. In the ESTK I can use #include script_name.jsx

This gives a couple of errors for each use in VSCode:

• Private identifiers are not allowed outside class bodies.
• ';' expected.

What am I missing? Hopefully it's an easy one to fix, I've not found any reference to private identifiers in my JavaScript or ExtendScript documentation.

Ian

[Klaus Göbel · Accepted solution]

Hi Ian,

try it this way: "//@include" instead of "#include"

[Ian Proudfoot]

Thank you Klaus!

For future reference where is this documented?

Ian

[Klaus Göbel]

Hi Ian,

it is not documented. I've got the answer from another (prerelease-)forum.

(https://forums.adobeprerelease.com/exmancmd/categories/estkvsc)

You can subscribe here: https://www.adobeprerelease.com/

[Ian Proudfoot]

Thanks for the link Klaus. Some very interesting information in there. Some of it makes me think that I should stay with the ESTK rather than make the jump to VSCode...

[Klaus Göbel]

Hi Ian,

I've tried it and I quit 😉

It makes debugging so much harder. And there is no progress since weeks (months).

And I don't want to waste my time. I had high hopes for myself, but now I've been returned to ESTK.

I drop in here from time to time, but nothing seems to change here.

[Ian Proudfoot]

Yes Klaus, I think that I am close to quitting. I chose this relatively quiet time to make the switch to VSCode, but it has been a disappointing experience. 
On a recent project I found the ESTK to be constanly 'going dead'. That is showing no signs of crashing, but only the user interface remaining responsive. Each time I would have to restart the ESTK and hope I had lost nothing.

Ian

[Klaus Göbel]

I have experienced something similar.
But that was mostly when there was a certain script error, like editing TextItems and setting the wrong offset or something similar.

In the meantime I have adapted my scripts to not create the most beautiful and shortest code, but to create the code in a way that I can debug most easily.
So there are several temporary variables that I can query easily and quickly

If you have script snippets, that force ESTK to crash, you could send it for testing purposes to me via PM.

[4everJang]

The BIG problem with ESTK is that it is no longer developed, meaning it will not work on my new 64-bit Windows machine. So I am forced to move to Visual Studio Code. After some hassle I got a basic setup working but unfortunately there is no live Object browser. I might have to write one in ExtendScript myself...

Once I get a working VSCode based system up and running I will start a new thread - or maybe a blog on one of my websites - to inform other scripters about the tricks to use. As ESTK development is dead, there really is no other choice than either moving to VSCode or giving up on scripting altogether.

[4everJang]

I am wondering who came up with the crazy //@include convention for Javascript in VSCode. It does work but now I need to write // //@include "some_file.jsx" to disable it and both lines are shown in green, as the editor sees both as comments. Please, VSCode developers, switch your brains on before you come up with the next great idea...  

[4XS Martin]

The BIG problem with ESTK is that it is no longer developed, meaning it will not work on my new 64-bit Windows machine.

By 4everJang

What problems did you encounter trying to get ESTK to work? I was able to install and use ESTK with out any problems on Windows 10(19043.1237) 64bit just recently.

[frameexpert]

I am also using it on Windows 10 64-bit. When running a script, ESTK seems to hang after it runs, so I am doing this for development and testing: I have my script open in both Notepad++ and ESTK. I edit and save in Notepad++ and run from ESTK. As ESTK is being slow recovering from the run, I switch back to Notepad++ to continue my edits. It is not perfect, but it is better than just using ESTK.

[4everJang]

I was looking for an installer package for ESTK but did not find anything - it used to be part of the FM installation package,  but since that is now a subscription it works differently, too. I do NOT want to reinstall FM just to have the ESTK added, as there are just too many details that will inevitably stop working once I start down that road.

Having said that, I am getting the hang of VS Code - which is a huge improvement over Visual Studio Community Editon (or any edition, for that matter) as the level of required geek knowledge is a lot lower. I am now seriously planning to build my own Data Browser to get live insight into which objects exist in the FM scripting layer and which properties they have. The ESTK Data Browser is kinda nice but has some serious usability flaws, anyway. If I get this done I will blog (and brag) about it so others can maybe use it, too.

[Klaus Göbel]

Hi Jang,

now it is downloadable here:

https://community.adobe.com/t5/framemaker-discussions/extendscript-toolkit-download-link/m-p/1079362...

It's no longer part of FM-Installation

PS: Nice to hear from you

[K.Daube]

My (growing) experience with VSC debugger shows that this debugger is not yet what we need ... Currently I often switch between the two.

Experiment	ESTK	VSCode
Close the environment	10 sec	instantly
Syntax highlighting	Reasonable, but less detailed than in EditPad	Reasonable; properties are displayed in green: KLD_M.sMarkerType = sItem; Undefined variables displayed in light gray
Variable display	Databrowser scrolls endlessly for variables. Focus lost for detail selection.	Local and Global variables in separate list
Target engine	Easy selection from list of installed FM’s	Two step procedure, less intuitive , connection to engine frequently lost.
Termination of script in case of error		Sometimes the Stop does not work
Pseuod-errors reported for referene to XML texts		oMenus.MenuDocu = KLD_M.UItxt.SetUpMenus.@menu01.toString(); @ → Identifier expected @menu01.toString() →  Experimental support for decorators ...