Batch actions are currently limited in the JavaScript side since you can't know how many documents your script will run against.

For context, I have many actions that have a dialog menu for options to select to customize the behavior of the actions. Unfortunately, without a way to know that the action is fully over, I have to make the user select the options for every document that they want to run individually, which prevents it from working as a "batch".

I have a few ideas for how this could be done, none of which are mutually exclusive:

1 . Add an event.numDocs property that tells how many documents are being run.

Pros: Incredibly simple setup, and the developer would just need to count down from numDocs until it reaches 0 to know when the batch action is over.
Cons: If the action is canceled or paused and re-run on a document, the count would be incorrect from then on.

2 . Add an event.batchId with some sort of UUID that would be different each time you start a batch action.

Pros: Also a simple setup. When the batchId is different from the previous one, you know to reset state
Cons: You have to work in a reactive way to the change. You wouldn't be able to reset any state or anything until the next time the action is run as there's no way of knowing that you've reached the final document or that the action was canceled.

3 . Add an event that can be subscribed to in the action for when the action is finished/canceled.

Pros: Gives you a way to respond to cancellations or the finish to perform cleanup or actions as needed.
Cons: Likely much more complicated setup for both Acrobat and script developers. Also, due to Acrobat's scripting for events being string function based, doesn't have a nice syntax or ability to work within closures.

I believe my preferred combination would be 1 & 2 together since that would give redundancy and the ability to do a final bit of code when the action has finished going over all the documents.

For anyone else with this problem, I came up with an initialization workaround for now that is much better than what is in the API Reference Docs. Although built-in functionality as mentioned above would still be much better.

The idea is to use time to determine whether the current document being processed is part of the same batch or the start of a new batch. Given that generally the files switch on the span of a few seconds at most, we can check if the time between the last command of the previous file and the first command of the new file is less than X seconds. If it is greater than X seconds, we assume that it is the start of a new batch.

This won't help if you need to perform an action specifically at the end of the batch, only the beginning.

At the very start of the action:

(()=>{
if(!global.batchTime || global.batchTime < new Date()){
global.batchContinue = false;
}else{
global.batchContinue = true;
}
})()


And at the very end of the action:

(()=>{
global.batchTime = new Date().valueOf() + 30000;
})()