Dear all,A crucial detail seems to be that the script to be run/debugged must be from the opened folder. Otherwise I get messages concerning missing/notfound targt although FM is open and the targt is addressed in the script by //@target framemakerFor scripts not needing the connection to FM the folder is not a requirement.My setup of launch.json: { "version": "0.2.0", "configurations": [ { "type": "extendscript-debug", "request": "launch", "name": "Run current file", "program": "${file}", "stopOnEntry": false } ] } FindingsWhen Debug is not active F11 switches the display to full screen. Obviously we are in a browser window and F11 triggers the kiosk mode ...It is not possible to step into the script with F10/F11 - this ... see above. To step into a script it is necessary to have at least one break point. From there on I can step with F10/11and continue with F5.I have not yet tested whether"stopOnEntry": truewould be helpful here.Breakpoints can be set by F9 on the code line or with the statement $.bp(condition)For JavaScript construct the automatic completion is already there, but the knowledge of the FM-DOM is a really missing feature.I wonder about the responsibility for this product. Information on community.adobe.com/t5/coding-corner/ confuses me. Display of variablesVSC provides a drop-down list for Local and Global variables - in ESTK they are not separatedWhen hovering over a variable which is not shown in full, the tool tip provides the full contents. This is very convenient for strings containing newlines.In contrast to the ESTK Data Browser the display is in my control. I do not see the scroll bar sliding up and down on every step and do not need to wait until has settled and can only then step further...{BTW I would appraciate a forum feature to highlight inline code appropriately - not just the code blocks}

K.Daube

Community Expert

Question

ExtendScript Debugger (ESD) in VS Code - first steps

Forum|Forum|5 years ago
November 2, 2020
3 replies
1061 views

Dear all,

A crucial detail seems to be that the script to be run/debugged must be from the opened folder. Otherwise I get messages concerning missing/notfound targt although FM is open and the targt is addressed in the script by //@target framemaker

For scripts not needing the connection to FM the folder is not a requirement.

My setup of launch.json:

{ "version": "0.2.0",
  "configurations": [
    { "type": "extendscript-debug",
      "request": "launch",
      "name": "Run current file",
      "program": "${file}",
      "stopOnEntry": false
    }
  ]
}

Findings

When Debug is not active F11 switches the display to full screen. Obviously we are in a browser window and F11 triggers the kiosk mode ...
It is not possible to step into the script with F10/F11 - this ... see above. To step into a script it is necessary to have at least one break point. From there on I can step with F10/11and continue with F5.
I have not yet tested whether

"stopOnEntry": true

would be helpful here.

Breakpoints can be set by F9 on the code line or with the statement $.bp(condition)
For JavaScript construct the automatic completion is already there, but the knowledge of the FM-DOM is a really missing feature.
I wonder about the responsibility for this product. Information on community.adobe.com/t5/coding-corner/ confuses me.

Display of variables

VSC provides a drop-down list for Local and Global variables - in ESTK they are not separated
When hovering over a variable which is not shown in full, the tool tip provides the full contents. This is very convenient for strings containing newlines.
In contrast to the ESTK Data Browser the display is in my control. I do not see the scroll bar sliding up and down on every step and do not need to wait until has settled and can only then step further...

{BTW I would appraciate a forum feature to highlight inline code appropriately - not just the code blocks}

Scripting

This topic has been closed for replies.

D

DanReedVistair

Participating Frequently

In the debuggers default mode (active), the debugger stays connected to that instance of FrameMaker.

This means whenever FrameMaker is restarted, you must then restart VSCode or it will still think it is connected to the old instance of FM.

This can be prevented by adding the following line to the launch config:

"extensionMode": "passive",

However, in passive mode, the debug can only be started by VSCode, not by FrameMaker.

If there is a primary version of framemaker you use, you can also add these two lines to the launch config:

"targetSpecifier": "framemaker-16.0",
"engineName": "main",

You can also create different launch configs for different FM versions and select them at the top of the debugger panel in VSCode.

The syntax highlighting is due to VSCodes built-in language server for javascript, so it will assume you are writing modern vanilla javascript.

There is not currently any language server specifically for ExtendScript, so it will have to do for now.

Always open a folder or workspace in VSCode. Only having a single file open will disable a lot of features.

If you have multiple discreet folders with your code in, you can create a new workspace, then use "File > Add folder to workspace" to add all the folders you need.

To change the colour of the text in the status bar you can add these two options to the launch config:

"selectTargetColor": "yellow",
"connectedTargetColor": "white",

K.Daube

Author

Community Expert

DanReedVistair, thank you very much for these explanations and hints.

K.Daube

Author

Community Expert

Concerning the synstax check

I do not know whether the syntax highlighting and checking is influenced by the debugger - or whether this is due to the file extension jsx. This leads to strange visual clues:

There is nothing wrong here - the scripts creates the dialogue:

Concerning the handling of this test environment

IMHO the start and end of VSC is far faster than that of ESTK. If something goes awry the close of VSC is insantly, while the close of ESTK takes a lot of time
In ESTK i frequently encounter the situation where FM must be restarted. This situation is much rarer with VSC-EDB.
VSC detects strange situations and prompts for a restart of the Debugging Host - in this case FM.
My impression is: I'm faster with my debugging than with ESTK

OFF TOPIC - strange message when trying to post the above:

W

Winfried Reng

Community Expert

Hi Klaus,

The forum error message is probably shown because you posted this twice although you deleted the first one.

Best regards

Winfried

K.Daube

Author

Community Expert

Today is not a good day for VSC-ESD:

I have multiple locations in which I maintain and test scripts. Some of these locations (folders) don't create problems, others do. Currently I try to continue with my project FMfindRepl. Two days ago I did not have problems to run/debug this script:

FM-15 is open and displays a file
The folder with the main script file is E:\_DDDprojects\FM-FindRepl\InstallThis
From there I have opened the main script FMfindRepl.jsx which contains include statements
At the bottom the debugger is indicated:

Short time after starting the script with F5 i get the message

I have tried various sequences of Open FM, Open VSC, Open the folder with the script, assure that in the folder of the script there is a sub-folder .vscode with a launch.json file in it...

Best solution might be: stop working, take a break or sleep and open Windows next day.

→ Again, there is no clear instruction how to get things running as expected.

I have just noticed a message at the very bottom which appears after I close the message "Can't start a session...":

This on(Double)Click.jsx is a script on which I was 'working' this morning. In the meantime Windows hibernated - and this is probaly not a good state for VSC-ESD...

K.Daube

Author

Community Expert

Concerning the target engine:

Somewhere I found the note, that at the very bottom of the window there is a yellow field "Select Target Engine". When clicking there, It opens on top of the window a selection list:

After selection the chosen target application is indicated at the same place - but nearly unrecognisable:

→ obviously my light theme does not provide the best visual clues. In a dark theme this white and yellow stuff would have been visible. But IHMO it should be the task of theme builder to check this out...

BTW I hate the dark schemes - they remind me of the time of blackboards in school and the first writing experiences on slate boards.

K.Daube

Author

Community Expert

post removed - should not be a nested post

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded