🚀 go-pugleaf

Nathan,

I looked at your form and it turns out that there is an internal problem with the document. Specifically, the field calculation order is not defined. This is necessary for automatic calculations to occur. I do not know why it's missing, but I suspect it's due to a bug in Acrobat. As you mentioned, others have reported this as well. It's not clear to me what versions of Acrobat this bug applies to.

What I did was replace the predefined calculations with custom JavaScripts, and it started to work. I'm not claiming this is sufficient to avoid the bug, but it's something to try.

Another approach is to avoid using a field's calculate event for this. It is often possible to trigger calculations from the dependent field's Validate event. This approach has a number of other advantages, mostly related to performance, and is usually what I prefer. If you'd like more help, post again.

George

I am having the same problem. I have really simple calculation fields, but when I distribute the form to my reader users it won't calculate. It doesn't matter if I have reader rights enabled or not (which I need to have the enabled). I don't know how to write Java Script. Any other suggestions? I also don't know how to post a sample of my form. Sorry.

Is there a convenient place to get simple javascript caculation examples? I don't know a lick about javascript either, but am certainly capable of figuring it out if I had a working example.

Same here....I could figure it out with an example.

Found this:
 <http://www.adobe.com/devnet/acrobat/pdfs/AcroJS.pdf>
and this:
 <http://www.adobe.com/devnet/acrobat/pdfs/AcroJSGuide.pdf>

Also, there is a pretty simple to follow example explained on this page. I'll let you know if it works.

 <http://www.acrobatusers.com/tutorials/2006/form_calculations>

Ugh, it worked just great until I saved it. Same thing all over again.

I think we have to figure out how to trigger the validation as George suggested in his last statement above.

For what it's worth here is the calculation I used that worked until I saved it:

event.value = this.getField("Name of field").value * this.getField("Name of Field").value;

This performs a simple multiplication. if you wanted it to add, you would use "+" instead of "*". a "/" would divide. You get the idea.

George,

I have figured enough java scripting to get my fields to function that way, but as soon as document is saved the problem is the same. I think you are right, setting the calculation order seems to disappear when it gets saved (at least after being enabled.) The option to reset it after it has been closed and reopened seems to completely disappear.

I don�t really understand the validation part of what you said in your post. I haven�t done much with the validation functionality. Is there a special javascript I need to know there as well? Does the validation have to happen on all the interacting fields, or just the field that has data entered into it?

thanks again ahead of time.

OK... I think I have this figured out now. Do the following in order and your calculations should work whether you use the simple calculations or javascript.

1) set all your form fields
2) set all your calculations
3) close and save the document
4) reopen document
5) enable for reader

If you add any calculations after it has been enabled, it will dump the calculating order.

I don't know how to set up the validations, so I haven't tested that out.

Nathan,

It's fairly straighforward to set up a custom validation script for this, but it might not be immediately obvious how to do it. I'll use your form as an example. In it, you have a number of rows with a Quantity field where the user enters how many items are needed, a Price field that has as its default value the price for the item, and a Total field which is a calculated field and should be the product of the Quantity and Price fields. The only variable in the calculation is the value of the Quantity field, so this will be easy.

The Validate event of a field gets triggered when the field value is committed. This happens when the user enters a value and presses Enter, Tab, clicks outside of the field, etc. What the script should do is take the value the user entered, multiply it by the value that's in the Price field, and set the value of the Total field. The script could look something like:



 
(function () {

    // Get the value of this field, as a number 
    var qty = +event.value; 

    // Get the value of the Price field, as a number 
    var price = +getField("PRICE.0").value;

    // Calculate the total 
    var total = qty * price;

    // Set the value of the Total field if not zero, 
    // otherwise, blank it out 
    getField("TTL.0").value = total ? total : "";

} 




What you really should do, however, is set up a document-level JavaScript (Advanced > Document Processing > Document JavaScripts...) that contains a function you can call from the QTY field of each row. The function will determine which row should be affected based on the field name that triggers it. Something like:



 
function calcTotal() {

    // Get the row number 
    var row = event.target.name.split(".").pop();

    // Get the value of this field, as a number 
    var qty = +event.value; 

    // Get the value of the Price field, as a number 
    var price = +getField("PRICE." + row).value;

    // Calculate the total 
    var total = qty * price;

    // Set the value of the Total field if not zero, 
    // otherwise, blank it out 
    getField("TTL." + row).value = total ? total : "";

} 




Than all you have to place as the custom Validate script of each of your QTY fields is the following:



 
calcTotal(); 




Also, make sure that you remove any calculations that you've set up on the Calculate tab of each TOTAL field. Now that the total fields do not rely on automatic calculations, it does not matter that the document is missing its calculation order piece, though this bug REALLY needs to be fixed. You should consider reporting it to Adobe. I will report it too.

Note that this code assumes the QTY and PRICE fields are numeric fields, meaning they will either be blank or contain a valid number. You've ensured this by setting up each with a Format category or Number.

George

Also, not that this approach will result in improved performance since each calculated field is not recalculated every time the value of any field in the form changes. A particular field's value is only recalculated when the fields that it directly depends on is changed.

George

George, I owe you one. I'll report the issue to Adobe.

George,

I have a similar problem, fields not recalculating when some of the dependant data changes. I am totally new at scripting and would appreciate your assistance for document level scripts.

I have:

a total field ("TotalAmountDue") which is dependant on

other total fields (the sum of "CostMemberWorkshop" + "CostNonMemberWorkshop" + "CostMemberDinner" + "CostNonMemberDinner"),

each which is the respective product of a total field ("NumberMemberWorkshop", "NumberNonMemberWorkshop", "NumberMemberDinner", "NumberNonMemberDinner"), each being auto calculated

based on respective hidden fields ("MW1" + "MW2" + "MW3" + "MW4") ("NMW1" + "NMW2" + "NMW3" + "NMW4") ("MD1" + "MD2" + "MD3" + MD4") ("NMD1" + "NMD2" + "NMD3" + "NMD4"),

(The hidden fields are populated based on the export value of radio/check boxes which contain and 'if ...else' statement)

and a set respective price field ("PriceMemberWorkshop", "PriceNonMemberWorkshop", "PriceMemberDinner", "PriceNonMemberDinner")

You can find my form (click on REGISTRATION FORM) at <http://www.sifmadiv.org/en/cev/30>.

If someone changes their selection of the radio/checkboxes, the hidden fields (which are populated based on the 'if ...else' staement are automatically and correctly updated, but the downstream totals are not.