Note: my sample code is jsx, but the problem may not be limited to jsx. Change the filetype of my provided files from txt to jsx prior to using!

We have multiple products that sometimes show a problem with document.close() not actually closing the file, leading to incorrect functioning, memory bloat, slowdowns, and we believe some crashes. I provide a test script that takes a currently open document and iteratively copies it, opens the copy, then closes the copy -- after the loop is finished, the copy files are removed.

Important: If run from the ESTK or Scripts Panel, the script works as expected -- no problems. If run from a custom menu (setup script also provided), the problem happens every time.

We believe we've seen this in cases where a custom menu is not the launch mechanism, and may be intermittent in those cases.

We believe we've seen this in InDesign Server as well. My scripts have been tested in CC 2019 and CC 2020 and on both Win and Mac.

In order to run the "Test_menu.jsx" script for using a custom menu, the "Documents left open on close.jsx" script must be in a "TestScripts" folder in your 'home' or 'user' folder (i.e., inside of "~/TestScripts").

This problem is a real headache and is difficult to work around. It affects multiple product areas; we urge prompt attention to this problem.

Thanks.

I'll attach a self-contained script which first creates in order to demonstrate problems with textStyleRange.convertToNote(). The script creates a small document containing "b"s. These are marked with a smaller pointSize so that they form individual textStyleRanges. The script then converts these textStyleRanges into notes. Unfortunately, the script terminates with a message: "Object is invalid; tsr.convertToNote()". This message happens because the scripting engine has become confused and is trying to convert a "b" within a note into another note. This shouldn't happen and is the first problem.

Open the story window. The beginning of the story has a clear pattern of notes between sentences. This should continue to the end of the document, but looking further down, two more problems can be seen:

(1) Overflow.jpg shows that the text at the frame's overflow boundary has become confused. It should say "The quick green fox ...", but instead it says something like "The The The quick The ...".

(2) Nearer to the end of the story, Confusion.jpg shows that larger phrases are converted into notes even though only "b" should be converted.

I can't attach a script, so here it is:

// Run this script in InDesign CC 2019, Roman Region.
//THIS IS THE PROBLEM PART THE REST IS JUST TO SET IT UP.

// Convert all "b" characters into notes
function hideNotes(story){

 // Find all the "b"s

 app.findTextPreferences = null;

 var findPrefs = app.findTextPreferences;

 findPrefs.findWhat = "b";

 var matchingItems = story.findText()


 // It shouldn't be necessary to copy the findText() results, but just in case ...

 var copy = []

 for (var i = 0; i < matchingItems.length; i++) { 

     copy[i] = (matchingItems[i])

 }

 // Loop through the "b"s and convert them to notes

 for (var i = 0; i < copy.length; i++) { 

     var tsr = copy[i].textStyleRanges.firstItem();

     tsr.convertToNote();

  }

}

// This is just setting up a document with reasonable defaults
function setup(){

// Set up application

var millimeterMeasurementUnits = 2053991795; // This means millimeters

app.viewPreferences.verticalMeasurementUnits = millimeterMeasurementUnits ;

app.viewPreferences.horizontalMeasurementUnits = millimeterMeasurementUnits ;


// Set up new document

var doc = app.documents.add();

doc.zeroPoint = [0, 0];

doc.viewPreferences.rulerOrigin = 1380143215 // This means PageOrigin;

doc.documentPreferences.pageWidth = 210

doc.documentPreferences.pageHeight= 297

doc.marginPreferences.left  = 20

doc.marginPreferences.right  = 20

doc.marginPreferences.top  = 20

doc.marginPreferences.bottom  = 20

// Set up new page

var page = doc.pages.firstItem();

page.marginPreferences.left  = 20

page.marginPreferences.right  = 20

page.marginPreferences.top  = 20

page.marginPreferences.bottom  = 20

// Set up new frame

var textFrame = doc.textFrames.add();

textFrame.geometricBounds = [20, 20, 277, 190];

// Add frame text

for(var i = 0; i < 250; i++){

    var insertionPoint = textFrame.insertionPoints.lastItem()

    insertionPoint.pointSize = 12

    insertionPoint.contents = "The quick green fox jumped over the lazy dog. "

    insertionPoint = textFrame.insertionPoints.lastItem()

    // This point size will set the "b" into its own textStyleRange

    insertionPoint.pointSize = 7

    insertionPoint.contents = "b"

}

}

//Entry Point
setup();
var stories = app.activeDocument.stories;
for (var i = 0; i < stories.length; i++) {

hideNotes(stories[i]);

}

It would be useful to be able to create an Event Listener that would fire when a document failed to open. It would be great if we could cancel the default behavior using the PreventDefault.

My use case is the following. We offer a script that adds a custom menu item to allow users to select, convert, and open files that aren't usually supported by InDesign. We want to be able to offer the same type of functionality if the user attempts to open one of our supported file types through the standard Open Dialog (File->Open).

We would set up an Event Listener for "failedToOpen," which would validate that the file is one we support. If so, we would PreventDefault and prompt the user, asking if they'd like the file converted. If we didn't support the file type, we would allow the default behavior.

Note: my sample code is jsx, but the problem may not be limited to jsx.

We have multiple products that sometimes show a problem with document.close() not actually closing the file, leading to incorrect functioning, memory bloat, slowdowns, and we believe some crashes. I provide a test script that takes a currently open document and iteratively copies it, opens the copy, then closes the copy -- after the loop is finished, the copy files are removed.

Important: If run from the ESTK or Scripts Panel, the script works as expected -- no problems. If run from a custom menu (setup script also provided), the problem happens every time.

We believe we've seen this in cases where a custom menu is not the launch mechanism, and may be intermittent in those cases.

We believe we've seen this in InDesign Server as well. My scripts have been tested in CC 2019 and CC 2020 and on both Win and Mac.

In order to run the "Test_menu.jsx" script for using a custom menu, the "Documents left open on close.jsx" script must be in a "TestScripts" folder in your 'home' or 'user' folder (i.e., inside of "~/TestScripts").

This problem is a real headache and is difficult to work around. It affects multiple product areas; we urge prompt attention to this problem.

Thanks.

Good morning. There is a sample script in InDesign that I LOVE! It makes contact sheets much quicker (and using far less memory) than Photoshop or Bridge. If you have a hundred images and want to make a contact page, this script is the way to go. Much more efficient. The Script is the ImageCatalog under JavaScript samples in the Scripts window. This has always been available, and always worked very well until the last couple of updates. Now when I run it, it just sits there. If I try saving the images again (save a copy) or saving them as a different format (jpeg vs tiff or tiff vs jpeg), sometimes it works. Again - I LOVE this script, and wish you would just make it a regular feature. Is there something I should be doing with my images before I run the script?

These are sample scripts that ship with InDesign. They show up under Windows / Utilities / Scripts / Samples / JavaScript / ImageCatalog.jsx. There is no vendor to contact other than Adobe for this one. There is another version of this under Windows / Utilities / Scripts / Samples / AppleScript / ImageCatalog.jsx, but I've never been able to get the AppleScript version to work.

Hi,
if I set value for snippetImportUsesOriginalLocation of documentPreferences to true, InDesign will place a snippet file with spread.place( snippetFile ) always at the current zero point [0,0].

Wheras I set the value to false the snippet will be placed at its original position.

It should be exactly the other way.

Currently value false will use the original position and value true will chose the current zero point as defined with app.documents[0].zeroPoint .

Tested with German InDesign versions:
CS6 8.1.0
CC 2014 10.2.
2020 v. 15.0.1.209
All on WIndows 10.

In the discussion linked to below Gerald Singelmann can see this also on a Mac OSX-version of InDesign:

https://www.hilfdirselbst.ch/gforum/gforum.cgi?post=573538#573538

Regards,
Uwe Laubender
( ACP )

Instructions:

1. Load Script4.txt into ExtendScript CC


2. Open ID CC 2019


3. Connect ExtendScript CC to ID CC 2019


4. Run the script


5. Observe that line 8 gives an "Object is invalid" error. That's because the nextItem() on line 6 didn't work.

To see this more clearly:

1. Load Script4.txt into ExtendScript CC


2. Open ID CC 2019


3. Connect ExtendScript CC to ID CC 2019


4. Comment line 6 and uncomment line 7.


5. Run the script


6. The script runs fine. It prints out "2", the name of the second page.

In other words, nextItem() is broken. The work around (in this case) is to use an index of "Page_263.index+1". I think, in other situations, the work around will require a loop.

Instructions:

1. Load Script.txt into ExtendScript CC


2. Open ID CC 2019


3. Connect ExtendScript CC to ID CC 2019


4. Run the script


5. Observe that the script gives an error on line 6 (Invalid object for this request.) This is because TextFrame281 and TextFrame284 are the same object. They should be different objects.

To see this more clearly:

1. Load script.txt into ExtendScript CC


2. Open ID CC 2019


3. Connect ExtendScript CC to ID CC 2019


4. Uncomment line 4 (var temp = TextFrame_281.id)


5. Run the script


6. The script runs fine. If you look in the document that has been created, the two text frames are in the upper right corner and they are linked to each other.

In other words, the value of TextFrame_281 changes, depending on whether it is accessed. My only guess is that this is some kind of lazy evaluation gone wrong.

Currently the only way to manipulate the undo queue is to run a script with doScript and even then it's very limiting. With my current event listeners, the user clicks around a few times and the undo queue fills up with 'Undo Set Scripting Tag' and they are unable to undo simple changes without holding down CTRL+Z for a few seconds. I am unable to use doScript because I need to return values to my interface. I would like to suggest an option to temporarily suspend undo tracking during certain script actions. Some of my actions do not change the document and only update the interface.