Answered
I would like to know how I know when to put a script in as a validation script or when to use a calculation script. I have seen many posts on the forum here that have similar scripts but sometimes they are put in as validation scripts and sometimes as calculation scripts.
For Acrobat forms at least, it possible to achieve the same results using either approach. I usually try to use Validation scripts that are implemented in document-level functions. Each field that the calculation depends on calls the function in the Validate event. The function collects the information and acts accordingly. I also find such code easier to understand and design. With calculation scripts, a lot of the dependencies are not clear by looking at a single field's script, and unnecessary use of global variables in such scripts (which is endemic) can lead to hard to track down bugs.
There are a number of problems that can occur with Calculation scripts if you're not careful. One of the biggest reasons to avoid them is due to the fact that a user can set a preference so that automatic calculations are not performed. This is fairly rare, but it's better to avoid the impacts of such a possibility.
Another big issue is performance. Because each calculation script in the form will get triggered whenever ~any~ field value changes, they can slow down your form unnecessarily. If you use the validation approach, the code only gets triggered when a field that the calculation depends on is changed. When you have a lot of field values changing at once the problem can be particularly bad.
Another problem has to do with the field calculation order. An incorrect order is very common and often not apparent, leading to incorrect results that can be hard to identify. If you use a lot of calculated fields, check the field calculation order frequently as you add and remove fields in the design phase. Confirming it should be on your check list of things to do before testing and deployment. I think it's better to minimize this problem by minimizing the number of fields that have calculation scripts.
One circumstance where you have to use a calculation scripts involves fields that do not have a validate event, such as radio buttons and check boxes. If such field values will only be changed interactively, as opposed to programmatically or by importing form data, then no problem. But if you need things to happen when a check box value is changed due to importing form data, then you need to set up a field with a calculation script that controls things. If changed programmatically, you have to use additional code or rely on a calculation script to control things.
With respect to these forums, a problem with calculation scripts is they are easier to provide than the equivalent validation script. You only have to place a calculation script in one field, whereas you have to place a call to a validation script in each field that the calculation depends on, and should use a document-level function. This is a problem because what I believe is the best practice takes too much effort to communicate quickly in a way that is as easy to understand as using a calculation script. So I'm often a hypocrite by suggesting folks do something I would not do in practice. But it gets the point across.
George