Validate Event Firing Too Often

[Former Community Member]

I'm using JavaScript to calculate conditional totals and I'm getting too many Validate events.



I've simplified the problem so it can be easily reproduced. Assume a form with three lines (subforms LineItem[0], LineItem[1], and LineItem[2]) and each line has two text fields (detail[0], and detail[1]).



In the validate event of each text field I've put a JavaScript call to postTotal( this ); The postTotal function is defined as:



function postTotal( cell )

{

var index = cell.index;

var name = cell.name;

var total = 0.0;



for( var i=0; i< Page1.Data.nodes.length; i++ )

{

if ( Page1.Data.nodes.item(i).name != 'LineItem' ) continue;

var firstNamedNode = Page1.Data.nodes.item(i).nodes.namedItem( name );

if ( isNaN( firstNamedNode.all.item( index ).rawValue ) ) continue;

total = total + parseFloat( firstNamedNode.all.item( index ).rawValue );

}

xfa.host.messageBox( 'total is ' + total );

}



Basically, all this should do is calculate a new total for either detail[0] or detail[1] depending on which column is updated. I realize that you could use FormCalc to do a summation but I'm actually doing conditional summations which cannot be done in FormCalc.



Whenever one of the detail boxes is updated I'm getting six validation events, in other words the event is firing for each one of the text fields even though only one has been updated. Why the extra validation events?



I can work around this by using the exit event in lieu of the validate event, but that's not the point. I'd like to know why validation is reoccurring on all fields even though only one has been changed.



Thanks

Mordechai

[Former Community Member]

To answer the question why the extra events, the object model will create an event dependancy list to keep track of what events need to be refired to complete the current event. Since you are using the Validate event, the document must validate ALL external dependencies. The single script function which loops through the nodes in each line item will cause the event model to add these fields to the dependency list. Logically if you assert 1 field for validity, then all fields which the script accesses must also be valid and hence the extra events.



I think it is the wrong approach to have each field doing a calculation with dependencies on other fields. In all of the samples I have seen so far, it is the total field which contains the calculation script. Since the total field has dependencies on each of the other fields, the script can fire only when needed (i.e. data entered into one of its fields).



I would suggest you have a hidden field containing the conditional sub-total for the line item and then move the calc script to a calculate event on the total field (which can be completely external from any of the subforms). You can still use the javascript within the script object to do conditional totals.

[Former Community Member]

The script loop only does a get operation on the values in the line item nodes. It seems to me that the the object model code that builds the event dependency list should in distinguish a set operation (which can change the value) from a get operation which does not change values and therefore should not fire a validation event. The initial validity assertion is triggered by an actual data change, i.e. entering a value in one of the fields. I don't see why that implies that any other fields used for readonly access should need to have their validity reasserted.



I agree with you that the conditional summation should be triggered from a separate total field rather than from the detail fields. That's the real reason I initially used the validate event because the total field's calculate event used a FormCalc expression to sum the detail items. Since I couldn't mix JavaScript and FormCalc in the same event, I used the validate event to trigger the JavaScript conditional subtotaling. I left that out of the example to keep it simple. Note that this still causes the extra validation events to be triggered.



I ended up just using the exit event on the detail fields. Since this was a dynamic form, there really is only one set of code to be maintained by the developer (although admittedly Form Server replicates the call to the JavaScript function multiple times when binding the detail fields to the underlying data records.)



The bottom line though is that I didn't expect a dependency to be generated from readonly references. I still think it's a bug in way the event dependency list is calculated.