Additional Information. It turns out it is possible to do a pre/post of editing the Job, Div, and DA tickets. So these operations will also trigger the before and after scripts.

I cannot see a way to do the post-process of the 'sdedit' on the Job/Division ticket and Document Assembly spec. Software-wise, the 'sdedit' has way too many permutations and uses and there is no way to insert a 'post-process' into the mix.

However, it should be possible to do the xyview. The use case makes a lot of sense and could be quite powerful, so I will add the ability to run an "after" script for "edit" and "view".

I like the idea of having the ability to create pre and post actions in the form of scripts.

I do understand that it could be more difficult/more work to implement the post action on the 'async' commands.

But it should not be impossible to do so.

I think that there are a lot of possible use cases where it does make sense to perform additional actions lets say after an Edit Division session.

Things like registering time/user into a workflow/admin system - or automatically create an up to date PDF, etc,...

So if possible I would like to see a post action also on the 'async' commands.

Continuation/Modification of point #4. It is possible to return the program (triggered from the menu) exit status to the "after" portion of the script. The custom script can then make decisions based on whether the menu command was successful. Some menu commands produce a pop-up after completion, but as stated, if the "after" script returns a "1", the follow on dialogs are disabled. So on error, if there is clean up work to do, you can do the work in the script, and disable follow on dialog boxes by returning a "1", or let them continue to let the user see the fact there was an error, by returning a "0".

Does this sound useful?

Of course, this does not apply to the menu items I originally mentioned as "asynchronous". There is no "after" for editing documents or the job,div, and assembly tickets.

If I was adding a mark trace level to a job and the process failed halfway through the list of divisions. In this case, if the script failed, I would want to run an "after" script to remove the trace mark from the divisions that had been successfully processed.

If this happens now, the traces can either manually applied to the remaining divisions, or the new mark is manually removed.