Steve Tibbett's Interactive Statements

Now that we’ve covered the basics of Action Builder and Conditions, lets take a look at Results.

Once all the conditions of for an Action have been met, all the Results are processed, one after the other in the order they are specified. We’ve tried to add Result types that cover a lot of the script we see in forms, and a lot of the questions we see posted to places like the LiveCycle Designer ES forum.

Here is a list of the Results currently available:

Many of these are self-explanatory, but a couple warrant a deeper look.

Set the Value of a Field



You can use this result to set a field to a particular value, or, for some types of fields, to special values. When you choose this result row type, you’re prompted to select an object. The options you get for the value you can assign are based on the type of object, and some of them are particularly useful.

When setting the value of a Numeric field, you can specify a numeric value, but you can also specify that you want the value set to the current page number, or the number of pages in the form. When setting a Date/Time field, you can specify a particular date, or you can specify that you want it set to today’s date.

For a Drop-Down List with values specified, you’re able to select the value from a list:

Call a Script Object Function



This is a great way to extend what’s possible with Actions without having to write script. A developer can supply a script object that can be dropped into a form, and then called using the Call a Script Object result.

So let’s say I have a Script Object that translates English text into Pig Latin. I want to make it easy for any form designer to use this script. What do I do?

Make it a Script Fragment. A user can then drag that script fragment into the hierarchy to add it to the form, and reference it from an Action.

Here’s what the Result row looks like for a call into a function called fTranslate in a script object called MyUsefulScripts:

The parameters you type in here are passed through to the function verbatim. The result can either be ignored, or assigned to a field. In this case we’re taking the result and assigning it to a text field.

The end result?

Without the form designer having to write any script by hand, they can use the script in the Script Object to translate text into pig latin.

Note to self, find more compelling demo…

As we discovered in Part 1, an Action is a list of Conditions, and a list of Results. Lets take a look at the Conditions. What choice are available in a particular condition row depends on the type of object you selected. A new, empty condition row just asks you to pick a node:

Click on “(object)” and a dialog appears with a list of all the nodes in the form that support conditions:

We saw previously that if you choose a button, you don’t get any further choices:

But let’s choose the Decimal Field:

Ah, more options. The condition and result rows are designed to read somewhat naturally, so although the spacing is a bit weird, it reads understandably.

Note that once you pick an object type for a condition row, the type is set – if you click on “DecimalField1″, the object picker window will only show you other decimal fields. If you want to start over with an empty row, hit the red minus button at the right of the row.

Here’s the complete list of conditions for a decimal field:

Some of these are more obvious than others, and the mapping from Actions to the XFA scripting events that exists under the hood is intentionally blurred a bit. For example, “is initialized” is pretty obviously related to the “initialize” event for fields, but what event does “is not” map to? That’s where Actions starts to get interesting.

This set of conditions will fire when the value entered into the field is >= 10 and <= 20. These two condition rows wind up generating a single line of script in a single event – DecimalField1′s change event. With Action Builder, you express your intentions and Action Builder figures out what code to write and where to put it.

This time the two condition rows each reference a different object: TextField1 and TextField2. This results in script being generated in the exit event of both TextField1 and TextField2.

But some conditions can’t be checked with an “and” relationship. For example it doesn’t make any sense to say “When Button1 is clicked AND when Button2 is clicked”, because you can’t click two buttons at the exact same time. If you try to create an Action that we can’t generate script for, we will try to tell you why:

Stephanie is going to talk more about trigger conditions and state conditions over on the LiveCycle Designer Exposed blog, so make sure you’re subscribed to that as well if you’re interested in this ongoing Action Builder saga. One last screenshot:

Next time, we’ll talk about results.