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.

Adobe have launched the next generation community resource!

This is a significant improvement on LiveCycle Café, as to now integrates LiveCycle with other Adobe resources. Including:

• Acrobat
• Connect Pro
• ColdFusion
• Flash Platform

The Café gives access to community and developer resources from RSS feeds to community forums. The application also includes samples and code snippets in Tour de LiveCycle and Tour de Flex.

Download it today!

The AIR application can be downloaded by clicking the Install below:

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.

Some events fire more often than others. Depending on what the designer is trying to achieve, this can be inefficient and may not have the desired effect at runtime. Another issue is the sequence in which events fire. A designer may have a requirement for several scripts to fire in a certain sequence. Having an understanding of how LC Designer and Acrobat fire events can help at design time.

I original had the idea of having a form that set out the pros and cons of each event and giving examples of script that could be used in each event. In the end, it has focused on the number of times that different events fire and the sequence. To view this form you will need Acrobat/Reader version 9 or above. This is because it contains script against the preOpen and postOpen events. Also it used setItems to populate the listbox.

The attached form has a lead-in page to introduce the different types of events and how to use the form.

The second page contains the “test area”, which is where you can decide which objects you are going to look at, via the dropdown list. There are textfields, numericfields, buttons, subforms, dropdown lists, etc. Some of the objects are standalone, while others are bound together. For example a textfield will have the following in the calculate event:

this.rawValue = textField2.rawValue;

Below the test area are counters for the three types of events (Process; Interactive; and Application). These show how often each event fires.

You can show and hide the different types of events, for example if you want to focus on a particular group.

Even though there are other objects in the form, only those in the test area are counted, as events fire.

All of the objects in the test area have scripts in each event. Generally these script are triggering the counters; however a couple are also binding objects together. This is useful in demonstrating the firing of calculate and validate events for objects that are bound.

There is a log showing the sequence in which the events have fired. When you go into the test area the log with automatically hide. Clicking the show button will make it visible again. Note that clicking the hide button will also clear the log.

There were quite a few challenges in developing this:

• The calculate; validate; and layout:ready events were bound by the counters. So it took several attempts to separate out the calculate and validate events from the counters, so that they did not run away with themselves.  In the end we broadcast the counter value out and the objects are not linked;
• Getting the log to record the events as they fired and have the most recent events visible at the bottom of the log. We used the new setItems script to populate the listbox with a global variable.

The form has some “interesting” script, but not much that has purpose in a real world form.

It is more of a point of interest to look at the interaction of events and how often some events like layout:ready fire.

The sample form is available here.

Allowing a user to move objects (in this case buttons) around the form. We wanted the user to be able position markers within a grid. The number (caption) of the button related to a particular solution in a table.

This solution is based on the “fly swatter” example by Thom Parker (http://www.pdfscripting.com) and samples by John Brinkman (http://blogs.adobe.com/formfeed/) looking at x, y, w and h properties.

The attached form contains three examples where buttons can be moved within set constraints.

• The first example has three sliders for setting red, green, blue values for an image.
• The second example uses a single slider to change the size of an image.
• The third has a series of markers which can be placed within a grid.

The basic approach is to set the x,y coordinates of the object based on the current mouse position.

You will notice that all three examples are in subforms which are located at 0,0 on the page. This is necessary so that the coordinates of the mouse will match the coordinates of the objects in the subform. If the subform was positioned down and to the right, then the script would need an offset constant.

The main script is in the exit event of the buttons. The first step is to establish the dimensions and position of the rectangle in which you will allow the buttons to move.

var gridX = xfa.layout.x(gridPICK);
var gridY = xfa.layout.y(gridPICK);
var gridW = xfa.layout.w(gridPICK);
var gridH = xfa.layout.h(gridPICK);

The next step is to get the dimensions of the button/marker:

var markerDim = xfa.layout.w(marker1) / 2;

We can then set variables for the x,y coordinates of the mouse position and for the new coordinates of the object.

var mouseX = event.target.mouseX;
var newX = (mouseX + "points").toString();
var mouseY = 595.276 - event.target.mouseY;
var newY = (mouseY + "points").toString();

The only step left is to determine of the x,y coordinates are within the rectangle or outside the rectangle. If the mouse is outside the rectangle then the coordinates are set to the rectangle boundaries.

if (mouseX <= gridX + markerDim)
{
   this.x = (gridX + markerDim + "points").toString();
}
else if (mouseX >= gridX + gridW - markerDim)
{
   this.x = (gridX + gridW - markerDim + "points").toString();
}
else
{
   this.x = newX;
}

The first two examples only move the buttons along the x-axis. Whereas the third example moves objects horizontally and vertically.

Because the script is in the exit event of the buttons, then movement is not in real time and requires the user to click twice. Once to activate the button and the second to position the button in a new position.

Not as smooth as other Flash/Flex solutions, but as best as I could achieve in LiveCycle Designer.

Suggested improvements are welcomed.

Sample form is available here.

Sometimes a person will develop a form and test it on their PC with Acrobat. When they are happy with the look, feel and functionality they will send it out to users. If the users have Reader then some of the functionality may not be available, leading to frustration.

LiveCycle Designer ES has a handy feature where the developer can set the target version of Acrobat/Reader and then check the warnings tab to verify that the form will work in that target version. However this does not take into account whether the form will be Reader Enabled.

The attached PDF does not present new information, merely gathers information on enabled features and restrictions together in one location. The information focuses on users who have the free Adobe Reader.

As I see it there are four possible options when deploying a form. The first considers when the users have Acrobat and the other three deal with Reader:

• All of the users will have Acrobat, so that the form does not need to be Reader Enabled. In this case there are no restrictions and the users will have full functionality;

• Where users have Reader and the form has not been Reader Enabled. This is the most restricted;

• When the form is Reader Enabled in Acrobat, users with Reader can save the form but they are still some features that are restricted. Note that certain licence restrictions apply;

• The last option considers the form being Reader Enabled using LiveCycle Reader Extensions ES (or ES2). The degree of functionality will depend on the options selected by the developer during the process.

The sample outlines what users will be able to do and what restrictions apply depending on how the form is deployed.

This example does not contain any script, its just a reference document. It was created using InDesign and exported to PDF. Buttons were added to provide the rollover examples.

The summary is available here.

I had been trying to access Acrobat menu commands from within an XFA form. Some of these are readably available, however the problem remained however as the command I wanted to access was restricted for security reasons.

There are a wide range of scripts that can be used to access menu items in Acrobat. However some of these are blocked for security reasons. There are a range of menu items that are still accessible; however the syntax is not always clear. This PDF (XFA form) provides the script for the Acrobat menu items that are currently permitted. It also has XFA equivalents and Acrobat JavaScript equivalents, where these are available. The form is set up so that you can access the scripts by clicking the buttons. The scripts appear in a dialogue and can be copied directly into LiveCycle Designer.

Still, armed with the list of commands I prepared a form in which to test each of the commands and create a library of commands that worked.

I have loosely grouped the scripts by function. You can preview the script by clicking the button. This allows you easy access to the script without having to open the form in LC Designer:

Accessing Acrobat menu items

The user can copy the script direct from the dialogue window.

Where there is an XFA equivalent, I have provided this as an option:

Alternative scripts are available

Lastly, where a function can be accessed via a menu item and via Acrobat JavaScript I have included this as well:

Acroform commands

At this stage I am reasonable happy that the list of scripts accessing menu items is complete (currently not restricted). In relation to XFA equivalents and Acrobat JavaScript equivalents, there may be some that I have missed.

This mini-project started out with the aim of having a list of Acrobat menu items that could be accessed in LC Designer. Clearly there is a wide range of other Acrobat functionality that is not associated with a menu that can be accessed via JavaScript. These are not cataloged here.

Here I am providing an updated version of the form. This version has not being signed, so functions like attaching a file now work.

The sample form is available here.