help with debugging an inDesign palette script from VSC

[jeffbottom]

hi all, I have quite a bit of experince with scriptUI for After effects but have hit a stumbling block with my first inDesign script.

the script needs to add pages to the document but this is not possible using a 'dialog' window. I switched to a palette window but it won't show up when launched from VSC. I read somewhere that  #targetengine "session"; doesn't work with the VSC extendscript debugger. So I tried placing the script directy in the scripts panel folder and the palette now loads great, but I can't debug it.

I've tried a few differnt launch.json configs but really have no idea what is going on.

if anybody could walk me through how to run and debug an inDesign palette from VSC it woudl be much appreciated.

[m1b]

Hi @jeffbottom, this probably won't be the complete answer, but for a start, in VSCode with ExtendScript Debugger, change:

#targetengine "session

to

//@targetengine "session"

I'm not convinced that's the root of your problem, but worth a try for now.

- Mark

[Dirk Becker]

Palettes only work within a permanent targetengine, not in the default transient engine named "main". Nothing new about that, and you've already read about #targetengine session.

As big change, the VSCode debugger does not scan the source for the #targetengine directive, and it won't create a new one accordingly. You have to specify a  preexisting targetengine in the launch.json "engineName" entry.

To create such a named engine, either use a startup script (otherwise blank) or app.doScript("#targetengine session" ... once.

The VSCode debugger also has two "request" modes - "attach" and "launch". The documentation from the help page explains the differences, I only use "attach".

launch.json also allows to specify a script file for "launch". Since I'm using attach, I instead use the "Eval in Adobe InDesign …" area in the bottom line on the focused script.

If InDesign is hesitant to get going, manually activating the process helps. Something about deeper sleep requirements of MacOS to preserve battery. Once the "attach" did its thing, this is rarely required.

When I have troubles to stop at breakpoints within ScriptUI callbacks, I isolate the calling code into another source, eventually with a separate breakpoint. I think this is more relevant to Illustrator though where ScriptUI callbacks require some more hoops. I'm working with the same script in both applications.

Be prepared that ScriptUI for InDesign has more, ummm, oddities comparing to other applications or versions a decade ago. Dialogs/palettes jumping around due to UI scaling, icons not showing in table/tree view, until they show up far later, colors getting ignored the same way as custom font specifications. Dropdowns showing misplaced by several thousand pixels, also mis-scaled, and so forth. If you don't like those issues, maybe give UXP a try – it has others, newer ones.

[m1b]

Hi @Dirk Becker, this is interesting!

As big change, the VSCode debugger does not scan the source for the #targetengine directive, and it won't create a new one accordingly. You have to specify a  preexisting targetengine in the launch.json "engineName" entry.

To create such a named engine, either use a startup script (otherwise blank) or app.doScript("#targetengine session" ... once.

This is interesting! So specifying the target engine in the launch config does NOT create it? That would explain some failures I've had in the past.

- Mark

[jeffbottom · Accepted solution]

hi all, thanks for the suggestions.

I wasn't really understanding the instructions on how to create the named engine but may have done it accidentally. After I had loaded the script once directly from the script panel in inDesign, I noticed that when back in VSC if I start the debugger there was now a "session" engine listed at the bottom of the drop down...

once attached, I was able to get debug feedback from the palette script. I have no idea what is actually going on behind the scenes but my palette is working and $.writeln() is writing to the debug console, woohoo.