When referencing objects in LiveCycle Designer ES2, you need to ensure that you are providing a sufficiently complete reference to the objects. If you do – the script will work; whereas if you don’t – the script may fail silently.

A sample form is available here.

Tip 1: name objects as you go!

First off you should name objects as you develop your form. This applies to pages, subforms and other objects like textFields and numericFields. When objects are named it makes it so much easier to reference them in script.  For example if we take an object (“myTextField”) which is inside a subform (“mySubform”), then referencing this object from outside the subform is straightforward:

this.rawValue = mySubform.myTextField.rawValue;

On the other hand if the subform is not named, it has to be resolved in the script first:

this.rawValue = xfa.resolveNode(“#subform[1].myTextField”).rawValue;

Both of the above scripts will work; however the second takes additional resources (xfa.resolveNode) and makes the script logic difficult to follow.

Tip 2: use Control+Click to insert references

LC Designer ES2 has a very handy tool, where you can insert the right amount of the object’s reference that is needed in the script. When you are in the script editor, hover your mouse over the object that you want to reference in your script. When you press and hold the Control key, you will notice that the mouse changes to a ‘V’. Now when you click the object, LC Designer ES2 will insert the correct reference into the script.

This feature is extremely useful and you should get into the habit of using it. Two big benefits:

• Your object references will be correct.
• You will be quicker scripting events.

A demonstration

The sample provides examples of how different objects are referenced, depending on the relative path in-between the objects.

On each pages there are three ‘lights’ that are controlled by their respective on/off button. In addition each page has a toggle state button, that controls each of the on/off buttons.

The main difference between the four pages is the manner in which objects are wrapped in subforms.

Notice that on page 4, the subforms have the same name, which allows the forms developer to use a loop script.

The form is available here.

As a forms developer, there are many options available to you when laying out your form. This post is not intended as a detailed explanation of forms design, merely a technical description of the specific options in LiveCycle Designer ES2 when using objects.

To keep users happy, you should consider the layout of your form. It is easy to pull objects into the form; however the manner in which you layout these objects and set the captions can affect the quality of the information that the user sends back to you.

Here is a sample form.

You can view the form in Acrobat/Reader. If you want to examine the script you will need to open the sample in LiveCycle Designer.

This sample demonstrate several options that are available to you. When you view the sample in Acrobat, the various options will appear to be quite similar. However the implementation in LiveCycle Designer is different for each one. The sample is a collection of objects, each one attempting to gather information about the user.

The usability of your form can be affected by a number of factors, including:

• font type and size.
• font weight and colour.
• paragraph alignment for the caption and value.
• spacing of objects and relative alignment.

Designing a form with a clear and crisp layout, will help the user complete the form.

Most objects in LiveCycle Designer come with a caption by default. The best solution is to use this caption, as it simplifies the layout process and form will render quicker.

When it comes to designing the form, we would recommend Forms that Work – Designing web forms for usability, by Caroline Jarrett and Gerry Gaffney. This is an excellent book that balances the technical aspects of LC Designer. You can get further information here.

This form demonstrates a few tricks albeit in a irreverent way. Firstly using an ‘Adobe’ grey as a background allows your form to be part of the application, rather than sitting on top it. The second uses script to allow the use to select a part of the puzzle and move it into the correct position.

This won’t be winning any prizes in the games market, however it is not intended to be a serious puzzle. It just demonstrates some of the dynamic features of LiveCycle Designer ES2.

When you open the form, the puzzle elements are spread across the page. The challenge is to get the pieces into the correct position, in order to see the hidden screen.

Because Adobe changed the application grey from 103,103,103 in Acrobat 8 to 51,51,51 in Acrobat 9 (RGB), we need a script in the initialise event in order to affect the colour of the rectangle on the master page:

if (app.viewerVersion >= 9)

{

background.value.rectangle.fill.color.value = “51,51,51″;

}

else

{

background.value.rectangle.fill.color.value = “103,103,103″;

}

this.access = “readOnly”;

The pieces are regular buttons with an image behind the button. The script that allows the user to move the pieces on clicking is a bit involved, but in essence monitors the x,y coordinates of the mouse on the click event.

Here is the final image you are striving for:

You can access the puzzle (sample form) here.

In case you don’t make it to the end of the puzzle, here is the video of Hook Head lighthouse.

Have fun!

Forms can de used to ask users questions. Sometimes the question is a simple yes or no. Other times you may have questions with more than two choices or with complicated scoring requirements. This sample will show you two options for keeping scores.

The first sample considers a series of yes/no questions. Each question is bound to a radio group where yes scores 1 and no scores 0 (zero). This is relatively easy to keep track of, because a simple sum function or addition of the rawValues will keep the overall score.

On the other hand, once you introduce more than two options, with differing marking schemes things can become a little heated.

The main thing is to plan out the approach first, as this can affect how you are going to name objects. For example in the second sample we have used a loop to look at each of the questions in turn. Using loops help keep your script lean and maintainable. But to get the most out a loop, it is easier if the objects have the same name. The loop then just looks at each instance of the specified objects.

Have a look at the sample which is available here:

The sample for is available here.

The main scripts are shown within the page layout. If you open the form in LC Designer you can dive right into the scripts. Please feel free to make changes and to adapt these examples to suit your requirements.

Good luck!

There may be situations where you only want the user to print a table with rows that contain data. This is particularly useful where a user is presented with a table containing many rows. Once the user has selected the rows that are applicable, the print buttons allow the user to print only the information that is relevant.

Here is a sample, which examines two options:

1. Hide the rows that are not selected before printing and then restore after printing.
2. Hide the page containing the table and show a hidden page, which contains a dynamic table that is populated with the rows that the user has already selected. After printing the original page is restored.

The form contains two print buttons with script in the click and postPrint events. When you have decided on a method, you could mode the portion of the script dealing with presence, to the prePrint event, so that the same behaviour will occur when the user selects print from the menu.

The click event of the print button hiding the null rows includes this loop:

for (var i=0; i<=13; i++)

{

var oRow = xfa.resolveNode(“Table1.Row1[" + i + "]“);

if (oRow.supply.rawValue == “0″)

{

oRow.presence = “hidden”;

}

}

We have also included a performance indicator, from John Brinkman’s blog. This indicates that the first option is more efficient, generally completing the hide script within 6 milliseconds. The second option’s performance decreases as more rows need to be duplicated on the second table. For example duplicating 14 rows took on average 35 milliseconds.

Overall, the first option is the cleanest, more robust and more efficient.

You can download the sample here.

The sample can be opened in Acrobat/Reader. If you want to examine the script you will need to open the sample in LiveCycle Designer ES2.