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.