Hello,
I've a function that applies an image processing routine and relies on a History Snapshot this way (pseudocode as follows):
Code: Select allcreate a Snapshot
user selects GUI values
apply routine with GUI values
loop:
- user changes GUI values
- restore Snapshot
- apply routine with GUI values
user is done:
- delete Snapshot
Which works fine, unless for a detail: if the user UnDoes after the Snapshot cancellation, he find himself not in the "before the Filter" status, but with an extra History Snapshot.
Is there a way to fix this (obvious, but unwanted) behavior?
Thanks in advance
Davide Barranca
Remove "Delete Snapshot" from History
-
codfisher
Remove "Delete Snapshot" from History
Depending on what I am trying to do I use:
Code: Select allapp.activeDocument.suspendHistory( "Name of History Item", "function_to_call()" )
This will replace all of the script events called from "function_to_call*()" with a single item in history named "Name of History Item". I usually wrap the whole script in one of these, so when the script is done, history just has a a single meaningful item. If the user undoes, it will be to just before they triggered the script.
And, If I am going to do a lot of layer manipulation, I create a new layerComp called "RESTORE" with the current state of the file, and then .apply() that layer comp to restore the file to the state it was in before the script ran, and then .remove() that layer comp when just before the script is done:
Code: Select alldocRef.layerComps.getByName( "RESTORE" ).apply()
docRef.layerComps.getByName( "RESTORE" ).remove()
I use .suspendHistory() in almost every complex script I publish to our team, and the RESTORE method gets called on error or cancel so that the file looks exactly the same at the end of the script as it did before the user started it, regardless of whether it ran correctly or not.
Code: Select allapp.activeDocument.suspendHistory( "Name of History Item", "function_to_call()" )
This will replace all of the script events called from "function_to_call*()" with a single item in history named "Name of History Item". I usually wrap the whole script in one of these, so when the script is done, history just has a a single meaningful item. If the user undoes, it will be to just before they triggered the script.
And, If I am going to do a lot of layer manipulation, I create a new layerComp called "RESTORE" with the current state of the file, and then .apply() that layer comp to restore the file to the state it was in before the script ran, and then .remove() that layer comp when just before the script is done:
Code: Select alldocRef.layerComps.getByName( "RESTORE" ).apply()
docRef.layerComps.getByName( "RESTORE" ).remove()
I use .suspendHistory() in almost every complex script I publish to our team, and the RESTORE method gets called on error or cancel so that the file looks exactly the same at the end of the script as it did before the user started it, regardless of whether it ran correctly or not.
-
undavide
Remove "Delete Snapshot" from History
Hello codfisher,
thanks for your reply.
My fault I've omitted a particular. I've been extensively using SuspendHistory myself, especially when a ScriptUI dialog is involved: this time the routines are called by an HTML panel and things are slightly different afaik, let me explain.
If you wrap the whole ScriptUI Dialog (creation, initialization, display, etc) with a suspendHistory, each user's interaction (slider change, input value, etc) gets wrapped too, resulting in a single, general, custom tagged history step no matter how many time the (update) routines are triggered by the user.
Conversely, a Panel can't do that: my setup launches a routine update each time the user changes a GUI value (say the slider). I can wrap that one, and the following ones, in a History Step, but I cannot wrap the whole panel - so to speak I can't say "Panel, from now on each thing you'll be doing is going to be in this History step, and don't record history anymore unless I explicitely instruct you to".
So I would be having a series of custom History steps, as many as the times the user has triggered the routine (which itself can be wrapped in a SuspendHistory).
That said, far from being ideal, the strategy I came up with is:
1. (History Snapshot + Routine) the first time the routine is launched.
2. User moves the slider: (Back to the Snap, Routine - I don't bother to wrap it with a SuspendHistory)
3. Either: User is done (delete Snap) or User Cancels (back to Snap).
Being 1,2,3 three different "phases" that, as opposed as with ScriptUI Windows, cannot be packed within a single SuspendHistory, I've to resort to that workaround - but I have the problem mentioned in the first post.
Kind regards,
Davide Barranca
---
http://www.davidebarranca.com
http://www.cs-extensions.com
thanks for your reply.
My fault I've omitted a particular. I've been extensively using SuspendHistory myself, especially when a ScriptUI dialog is involved: this time the routines are called by an HTML panel and things are slightly different afaik, let me explain.
If you wrap the whole ScriptUI Dialog (creation, initialization, display, etc) with a suspendHistory, each user's interaction (slider change, input value, etc) gets wrapped too, resulting in a single, general, custom tagged history step no matter how many time the (update) routines are triggered by the user.
Conversely, a Panel can't do that: my setup launches a routine update each time the user changes a GUI value (say the slider). I can wrap that one, and the following ones, in a History Step, but I cannot wrap the whole panel - so to speak I can't say "Panel, from now on each thing you'll be doing is going to be in this History step, and don't record history anymore unless I explicitely instruct you to".
So I would be having a series of custom History steps, as many as the times the user has triggered the routine (which itself can be wrapped in a SuspendHistory).
That said, far from being ideal, the strategy I came up with is:
1. (History Snapshot + Routine) the first time the routine is launched.
2. User moves the slider: (Back to the Snap, Routine - I don't bother to wrap it with a SuspendHistory)
3. Either: User is done (delete Snap) or User Cancels (back to Snap).
Being 1,2,3 three different "phases" that, as opposed as with ScriptUI Windows, cannot be packed within a single SuspendHistory, I've to resort to that workaround - but I have the problem mentioned in the first post.
Kind regards,
Davide Barranca
---
http://www.davidebarranca.com
http://www.cs-extensions.com