Copy link to clipboard
Copied
Hi,
In our InD plugin, we are invoking jsx scripts from C++ code (using RunJavaScriptFile). I would like to know how to debug these scripts as I single step in the VS debugger. At the moment, I am doing it the hard way using alerts, but that is slowing me down a lot. I tried hunting the documentation but am unable to identify any reference for the same.
Appreciate the help.
Thanks,
Why not debug the script using Extendscript/VS Code debugger. I don't think the VS debugger would be able to debug the script. What I would try doing is run the plugin to the point where the script is called and then break the flow of the plugin so that the environment(document state etc. is set exactly like it would have been when the script was called via plugin) is setup correctly, and then launch the script using Extendscript/VS Code to debug the script.
-Manan
Copy link to clipboard
Copied
Why not debug the script using Extendscript/VS Code debugger. I don't think the VS debugger would be able to debug the script. What I would try doing is run the plugin to the point where the script is called and then break the flow of the plugin so that the environment(document state etc. is set exactly like it would have been when the script was called via plugin) is setup correctly, and then launch the script using Extendscript/VS Code to debug the script.
-Manan
Copy link to clipboard
Copied
Hi,
So, here is what I understand:
1. In VS debugger, single step until the line "scriptRunner->RunFile(fileSpec, params);", which invokes the jsx file
But after this, it appears that you are suggesting me to shift to VS Code, but I don't exactly get the steps to perform. Also, what did you mean by "break the flow of the plugin" since I am single stepping in VS debugger until that exact point of hand-off of the execution from C++ code to Jsx.
Thanks,
Copy link to clipboard
Copied
After step 1, stop the execution of the plugin. This will depend upon where your code is, I can't predict the actual way to do this. It might be by using the return statement, moving the debugger to the end of the current method, etc. The idea is that the plugin should not execute any code that changes things that will have a bearing on the outcome of the script. After this, it's just a matter of debugging the jsx code as it's done normally using ESTK or VSCode.
-Manan
Copy link to clipboard
Copied
RunScript params has a method "SetInvokeDebugger()...
I haven't used in in a while and never with VSCode, though.
Also, are you aware of ExtendScript methods such as "$.bp()" and "$.writeln()" ?
Copy link to clipboard
Copied
Hi,
No, I am not aware of debugging jsx files / Extend Script. I will read those up. If there is a reference in context of InD plugin development, that will be really super helpful.
I will also check SetInvokeDebugger as well.
Thanks
Copy link to clipboard
Copied
@Dirk Becker, this is interesting. I never saw or used this. If set to true, does it launch the debugger, i.e., ESTK automatically, or some configuration needs to be done?
-Manan
Copy link to clipboard
Copied
Manan, my source where I last tried that flag is surrounded with preprocessor tests of InDesign version 4 / CS2 (when the flag was introduced, back then a direct parameter to RunFile) and otherwise sets it to false, so please forgive if I don't remember the details.
I have not yet used VSCode for debugging JSX, my recently "retired" main development machine had a working ESTK, and I still got spare machines and/or VMs if I need it. After I used VSCode for my current node.js project (the project file utilities mentioned in a different thread) I'd rather revive my own debugger project than use VSCode for InDesign scripting. Or stick to plug-ins in the first place.
Note to asaxena - if you can't get ESTK going at least in a VM, I'd still recommend to refer to its Javascript tools guide document for details on ExtendScript.
Copy link to clipboard
Copied
I will take a look at it when I get some time, have very little to do on the plugin end these days so it's a chore to setup a testbed and investigate. I am personally sticking to ESTK as long as I can. I somehow don't like VSCode, but it is becoming all-pervasive especially for JS development with its integrations including debugging lots of stuff.
-Manan