I've been thinking about this: One of the stellar aspects of PDF-XChange is the robust JavaScript support (besides the great tech support, that we don't have to use a subscription, the UI, all the great functionality...) It allows me to make scripts when there's something repetitive or inconvenient and not rely on it being part of the software.
I agree that it is a mess when all the individual actions a script may do become individual undo items, so making it default to not record undo's during scripts feels like a simple workaround: However, allowing a script to run and make changes to a pdf without any evidence of those changes seems like both a security issue and counterintuitive for a user.
Ideal in my mind would be the following:
- By default, actions that change the document are recorded in the script individually.
- If a user doesn't like the mess this causes, there could be a preference option to not record scripted changes to undo.
- Scripts can invoke a queuing mechanism such as begin/endUndoQueue() and a way to either discard that queue or save it (ie if a script makes temporary changes to a document it would be good to be able to discard them along with the temporary change - see 'preview' in the hatch script listed below)
I understand it's a big ask, as I have no idea how that could really be implemented and not break scripts that go to other PDF applications. I think it would add hugely to the JavaScript power in PDF-XChange, because scripts could work like built-in functionality.
An example of a script that adds multiple undo steps from one script run is my mirror annotations tool:
viewtopic.php?t=39917
An example of a script that makes changes to the document that are invisible to undo is my hatch tool:
viewtopic.php?t=40329