Have you ever struggled to figure-out what item from a list (list box or drop down list) a user had just selected in the list’s Change event? If so, it’s possible you were trying to use the

rawValue

property in order to get at this information.

Unlike other objects such as exclusion groups, the rawValue property of a list object doesn’t reflect the new selection until the selected value is committed to it (by the user tabbing or clicking away from the list). That means that if you’re trying to, say, make a certain field visible at the moment when a particular item in the list is selected, you can’t use the rawValue property because it still contains the old (previous selection) value.

Instead, you must use the

xfa.event.newText

object/property of the Change event itself and possibly the list object’s

boundItem

function in order to determine the value associated with the new selection.

When scripting any XFA event, you always have access to properties (information) of that event via the

xfa.event

object. In the case of the Change event (which occurs when the list’s selection changes), the

xfa.event.newText

property is of particular interest because it contains the text portion of the item that was just selected in the list. It’s important to note that this is only the text portion because if your list contains items with values that differ from their text (you’ve associated both a text and value part to each item in the list), you’re probably even more interested in determine the value associated with the new text that was just selected in the list. Fortunately, that’s an easy problem to solve as well:

this.boundItem( xfa.event.newText ); // JavaScript
$.boundItem( xfa.event.newText ) // FormCalc

will return the value bound (associated) to the text from the list’s new selection.

So there you have it: When handling a list object’s (list boxes or drop down lists) Change event, don’t rely on the rawValue to get the new selection: Use xfa.event.newText and boundItem(text) instead.

---

Posted by Stefan Cameron on September 23rd, 2006
Filed under Events,Scripting

---

I just learned something very interesting while answering a forum thread just now which I thought I should share with the rest of you.

In all the scripts I’ve written so far, I had never realized this simple rule: When writing calculation scripts to set the value of certain fields, the line in your script which assigns a value to the field on which the Calculate event was fired should always be the last line in your script. This is because the last-executed line in your script is the one that the XFA Object Model will use to determine the value of that field.

While it’s generally not recommended to do much more than set a field’s value in the Calculate event, reality is that most of us use it for much more than that: Since it fires on all fields on a form after a field’s value changes, we may use it to affect the presence, color, dimension, etc., of some fields which depend on the values of other fields. Therefore, it’s very easy to fall into this trap where your calculation script isn’t working probably simply because you haven’t structured it correctly.

Take the following FormCalc script as an example:

if (NumericField1 > 0) then
	NumericField1 * 10;
	$.presence = "visible";
else
	0;
	$.presence = "invisible";
endif

This scripts runs in the Calculate event of a numeric field and, if NumericField1’s value is greater than zero (0), results in the field becoming visible and its value set to the product of NumericField1’s value multiplied by 10. If NumericField1’s value is zero (0) or less, its value is set to zero (0) and it becomes invisible. Note the order of the lines which set the field’s value and the ones which set its presence: The value is set before the presence is set.

The result of this script is that the presence is affected properly depending on the value of NumericField1 however, since the last-executed line is “$.presence = ‘visible’” (or “invisible”), the value acutally assigned to the field is “visible” (or “invisible”) which evaluates to “0” as a numerical value. Therefore, with this script, the value of the product field would always be zero (0).

If you change the order of the lines which set the field’s value and presence as follows:

if (NumericField1 > 0) then
	$.presence = "visible";
	NumericField1 * 10;
else
	$.presence = "invisible";
	0;
endif

Then both the field’s presence and value will be set correctly because the last-executed lines in each block are the ones which set the field’s calculated value.

---

Posted by Stefan Cameron on May 15th, 2006
Filed under Events,Scripting

---