Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

'Scripting' Category Archive

What About the Other Field?

A common need in forms is to ask the user to choose between a set of options within a list, be it a radio button list, list box or drop down list. What’s more is that these lists often include an “other” option to let the user specify something more specific that isn’t included in the list. The trouble is, how do you ensure that the user fills-in the “other” field prior to submitting their form?

I thought it might be useful to provide a sample form which demonstrates how to build a list field which has an “other” option and clicking on the “other” option displays a field for entering the specific value and makes that field required — but only if the user chooses the “other” option. (You wouldn’t want the “other” field to be hidden and required or else the user would never be able to submit their form since Acrobat would prevent the submission on the premise that there’s an un-filled required field somewhere.)

“Other” Fields in Acrobat/Reader 8.1+

The first thing I did was create my sample form using Designer 8.1 and Acrobat 8.1. That was very easy and just as straight-forward as I expected it would be: One radio button list, one list box and one drop down list, each set to be required and with their own “other” item and script to show their respective “other” field (and make it mandatory) when their “other” item is selected and hide it (and make it optional) when their “other” item is de-selected. Add a submit button and Acrobat/Reader 8.1 automatically takes care of preventing the submission if any required field isn’t filled.

To keep things simple, each list field has script that detects when the user either selects the “other” item or an alternate item and sets the presence and mandatory properties of its “other” field to be visible/required or invisible/optional, respectively.

Download 8.1 sample [pdf]

Minimum requirements: Designer 8.1, Acrobat/Reader 8.1

“Other” Fields in Acrobat/Reader 8.0 or Earlier

Unfortunately, I didn’t have the same kind of experience getting this form to work in Acrobat/Reader 8.0 or earlier.

The first thing I did, since my 8.1 sample form doesn’t use any functionality only available as of Designer/Acrobat 8.1 (in fact, it uses XFA properties and script functions that have been available since Designer/Acrobat 7 and likely even earlier), I simply used Designer 8.1 to set my form’s Target Version to Acrobat/Reader 7.0.5 and figured I would open it in Acrobat 7.0.9 and all would be good. Well, that wasn’t the case.

Aside from Acrobat not respecting the “required” setting on the radio button list (which was expected since required radio button lists weren’t supported until Acrobat 8.0), I discovered a very strange behaviour in the list box where simply having a statement within its Change event that sets a field’s mandatory property to “error” will always result in that field being required, as far as Acrobat/Reader is concerned, even if the statement doesn’t appear ever to be executed on form initialization. The result is that selecting an item other than the “other” item in the list box and attempting to submit the form prompts Acrobat to cancel the submission because a required field isn’t filled. The problem is that the required field is the list box’s “other” field which is hidden from view because it isn’t supposed to be required. Finally, there was also another issue with list boxes that have Change event script: Their value is never committed to the Data DOM, which means that the list box always appears to have no value and that also prevents the user from being able to submit the form because the list box appears never to have been filled (even though an item is clearly selected).

So the are three problems with the 8.1 sample form when it’s running in versions of Acrobat/Reader prior to 8.1:

  1. Although properly supported in Acrobat/Reader 8.0, radio button lists can’t be set to “required”;
  2. List boxes with Change event script containing a statement which sets a field’s mandatory property to “error” results in that field always being “required” (this strange issue is resolved in Acrobat/Reader 8.1); and
  3. List boxes with Change event script don’t commit their value to the Data DOM (this is also resolved in Acrobat/Reader 8.1).

Fortunately, issues #2 and #3 can be resolved fairly easily simply by not using the Change event. The only viable alternative I found was using the Exit event instead. (Note that in the Exit event, you have to use the list’s “rawValue” property to determine its value rather than using the “xfa.event.newText” property as in the original Change event script.)

Issue #1 (required radio button lists not supported) can also be resolved although it requires a little more work. One alternative is to use the “Two Button Submit” Technique I described on a previous post on Complex Validations, which is what I implemented in my 7.x sample form.

Download 7.x sample [pdf]

Minimum requirements: Designer 7.0, Acrobat/Reader 7.0


Posted by Stefan Cameron on August 7th, 2007
Filed under Acrobat,Bugs,Events,Scripting,Tutorials

LC Designer ES Documentation Now Online

Adobe recently published a whole collection of documents for Designer. In particular, Designer documentation is now available online via LiveDocs.

Under the Develop Tab, you’ll find documentation on the following topics as they pertain to Designer:

  • Designer Help (LiveDocs)
  • Form Guides (“getting started” guide)
  • Scripting Basics
  • Scripting Reference
  • Target Version Reference (to know what features of XFA and Designer are supported in specific versions of Acrobat — this is what the new Target Validation feature in Designer is intended to help you manage)
  • Transformation Reference (to know what’s supported if you’re targeting HTML)
  • FormCalc Reference

Posted by Stefan Cameron on June 25th, 2007
Filed under Designer,FormCalc,Scripting,Tutorials

Adobe Unveils LiveCycle ES

Today, Adobe unveiled its new LiveCycle Enterprise Suite. It includes a whole slew of new product versions all designed to work together in an IDE (Integrated Development Environment), bringing PDF and Flash together in the same workflow using a new technology called Form Guides (see the Generate dynamic Adobe Flash® Player compatible form guides topic in the LC Forms ES feature list). Form Guides enable you to add an RIA (Rich Internet Application) view to your form to engage your customers in a more compelling way.

What’s more is that the new Enterprise Suite launch means that there’s also new version of Designer: LiveCycle Designer ES (version 8.1). I believe this will be an upgrade to Designer 8.0 which currently ships with Acrobat Pro 8.0. Most notable in this new version are

  • the new Guide Builder tool which will help you quickly re-purpose your PDF form as a Flash-based Form Guide;
  • a new feature called Form Fragments which will enable you to re-use sections of your forms and scripts in other forms while only needing to make changes in one place;
  • a Syntax Checker in the Script Editor to check for errors in your scripts (this will definitely help with debugging!); and
  • the Target Validation feature which will help you determine which XFA features you may use when targeting a specific version of Reader/Acrobat (e.g. if you specify Reader/Acrobat 7.0 as your target version and you insert a table into your form, you’ll get a warning telling you that tables aren’t supported in Reader/Acrobat 7.0 — they’re only supported as of Reader/Acrobat 7.0.5).

Posted by Stefan Cameron on June 4th, 2007
Filed under Debugging,Designer,FormCalc,Scripting

It's almost here: A book on Designer!

I’ve lost count of how many times, over the past year, I’ve been asked if there was a good book on designing forms using LiveCycle Designer. Until now, the answer was always an unfortunate “no”.

Well, I’m very happy to announce that J.P. Terry from SmartDoc Technologies has been hard at work over the past few months on a book titled, Creating Dynamic Forms with Adobe LiveCycle Designer.

Based on some of the chapters I’ve reviewed so far, this is going to be an excellent resource for those of you who might not know where to start or perhaps would like a few pointers on good form design. I, for one, am really excited about this since it’s the first (of hopefully many more to come) book about the product and technologies I work on every day. It’s almost like a milestone — Designer’s first book.

No word yet on a specific release date but I’ll keep you all posted as I get more details over the coming months.

So how about you? Are you looking forward to a book on Designer and dynamic forms?


Posted by Stefan Cameron on May 18th, 2007
Filed under Books,Designer,Instance Manager,Scripting,Tables,Tutorials

Where did that border come from?

Have you ever wondered to yourself, "where did that border come from?", when you simply wanted to set a field’s fill color? I know I did for a while until I learned about how the quirkiness of borders in XFA.

For example, if I wanted to set a field’s background (fill) color to green in a button’s Click event, the first thing I would do is:

this.fillColor = "0,255,0";

or

this.border.fill.color.value = "0,255,0";

Both methods amount to the same result which is the following:

Notice the black edge that appears around the perimeter of the field. What is that doing there? All I wanted to do was set the background color to highlight the field!

What I really wanted was this:

Is that too much to ask? All I did was set the fill color; I never messed with the edge, honestly!

In order to understand where that black edge came from and how to make it go away, we’ll need a better understanding of how borders are specified in XFA.

XFA Borders

First of all, the term "border" signifies all elements that compose the rectangular area that surrounds the entire field or the field’s value (two distinct borders). That means it’s made-up of corner, edge and fill properties, amongst others. In Designer, the field’s border is edited via the Border palette and the field value’s border is edited via the Appearance property on the Object palette’s Field tab.

Next is the fact that unlike most other XFA elements, the mere presence of the <border> element, and of some of its child elements such a <fill>, determine what the field’s border will look like. For instance, if no <border> element is specified, the field does not have a border even if the <border> element has a presence attribute with a default value of "visible". Likewise, if the <fill> element isn’t specified, the border has a transparent fill (i.e. no fill) even though it, too, has a presence attribute with a default value of "visible".

For example, the following field definition has no border:

<field></field>

If the <border> element is specified, then you also get the default <edge> element which is a thin black line and since specifying only a single <edge> element affects all sides of the border, you end-up with a black edge surrounding the border — just like in the first image above (without the green fill).

In this case, the field’s definition is simply this:

<field><border/></field>

When you use the script I proposed earlier for setting a field’s background (fill) color to green, this is what you get in the XFA syntax which describes the field:

<field>
    <border>
        <fill>
            <color value="0,255,0"/>
        </fill>
    </border>
</field>

As you can see, the <border> element has been specified and therefore the border gets the default thin black edge (even though an <edge> element wasn’t explicitly specified since an edge is implied when not explicitly specified).

Finally, edges and corners are a little tricky because there can be as little as none or as many as 4 <edge> and <corner> elements specified. What you need to remember is that they’re defined in clockwise order:

  • No <edge> element is the same as a single <edge> element which defines all edges at once (all 4 edges are identical).
  • Two <edge> elements define the top/bottom (edge 0) and left/right (edge 1) edges.
  • Three <edge> elements define the top (edge 0), left/right (edge 1) and bottom (edge 2) edges.
  • Four <edge> elements define the top (edge 0), right (edge 1), bottom (edge 2) and left (edge 3) edges.

The same goes for the <corner> element.

The Solution

So just how is it that we get rid of that edge? Well, given that the edge is implied (as mentioned earlier), all we have to do is hide it! It’s quite simple, in the end, yet quite frustrating if you don’t understand how borders work in XFA.

The <edge> element has a presence property which you can set to "hidden" in order to hide it. Therefore, the following script would set the field’s background (fill) color to green and ensure that the default black edge doesn’t appear along with it:

this.fillColor = "0,255,0";
border.edge.presence = "hidden";

That JavaScript, on a button’s Click event, will yield the border as I intended it to be (in the second image mentioned earlier).

Fun With Borders

In order to demonstrate a few things that can be done with borders using script (you may use similar scripts to show/hide borders on fields or field values for all kinds of purposes), I’ve provided this sample form. I encourage you to open it up in Designer and look at the script in order to get an idea for how you might implement your own border solution.

Download Sample [pdf]

Minimum Requirements: Designer 7.1, Acrobat 7.0.5.


Posted by Stefan Cameron on March 24th, 2007
Filed under Scripting,Tutorials