Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

'Bugs' Category Archive

Multi-Selection List Schema Definition

After spending some time, recently, showing you how to connect your form to a schema and highlighting Designer’s support for schema metadata, I thought I would round-off my current train of thought on schemas by tackling multi-selection listboxes. Since they store their selected data in <value> nodes, once you think about it, their schema definition may not be obvious. When you’re working with XML data that isn’t governed by a schema and namespaces, it is perhaps easier to work with (i.e. accept) these <value> nodes however things change when you have a schema telling you how your data must be structured and scoped (with namespaces).

Continue reading…

Posted by Stefan Cameron on September 30th, 2009
Filed under Acrobat,Bugs,Data Binding,Scripting,Tutorials,XFA

LiveCycle Designer 8.2 Update

I wasn’t sure I could actually blog about this update due to licensing issues but hey, they just did on the LiveCyle Blog. I guess it’s all in the wording.

In particular, this 8.2.1 SP2 update resolves a nasty bug where your form would grow to multiple megabytes in size due to a processing instruction (PI) being repeated thousands of times for a particular field. The PI looks like this (though the value, ‘aped3’, may differ):

<?templateDesigner StyleID aped3?>

Thankfully, this bug doesn’t occur often but when it does, the most common symptoms are:

  1. reduced performance when working in Designer;
  2. form file bloat (into the multiple MBs); and
  3. crashes when working in Designer with the form open.

If you can’t update Designer due to your licensing agreement and you come across this bug, you’ll need to go to the XML Source and look for a processing instruction like the one quoted above. It’ll be there many, many times. Just delete all occurrences. If your form is saved as an XDP, then you can exit Designer and open it in Notepad (or some other text editor) and delete it that way as well. Then re-open it in Designer.

Updated: March 28, 2009

Posted by Stefan Cameron on March 17th, 2009
Filed under Bugs,Designer,LiveCycle

MAX 2008 Tutorial – Part 3 – Form Guide

Welcome to the third and final part of a three-part post series tutorial on importing data into a form guide and a PDF. The first part covered the form design, the second part covered the Flex code and the third part will cover designing and debugging the form guide that will complete the solution.

Form Guide Layout

The goal is to design a form guide which will provide two panels: one for user options and the other for results.

The first panel will expose the 4 fields inside the GuideObjects subform (which are only meant to be exposed in the form guide — hence why the GuideObjects subform has the Initialize script to hide it if the host isn’t “Flash”). The user will have the option to choose an actor and/or category for further filtering and will then click on the GetMovies button to execute the request on the Movie Service. When the requested XML is returned to the form guide, the GetMovies result handler will convert the XML into instances of MovieRow inside the Listing table.

The second panel will use a repeater layout to expose the Listing table’s contents within the form guide however this panel will only be accessible if the movie query returned 1 or more results.

Once the results are in, the user will then be able to switch (“flip”) to the PDF view which will show the Listing table in the form, from which the user could then print or archive the results.

Continue reading…

Posted by Stefan Cameron on November 19th, 2008
Filed under Acrobat,Bugs,Conferences,Debugging,Form Guides,Scripting,Tables,Tutorials

Digital Signature Field Status

Have you ever needed to verify the status of a digital signature (“DigSig”) field in a form? A typical scenario would be that a form is to be signed prior to being submitted and you don’t want the submit button to be available until the user has successfully signed the form. Unfortunately, the “lock fields after signing” feature, available as of Designer/Acrobat 8, won’t be enough in this case because it’ll only lock the fields after a signature has been applied; it won’t also make the submit button visible/enabled.

There’s a feature in Acrobat’s scripting object model that lets you determine the status of a DigSig field (i.e. whether it’s signed or not): It’s the AcroForm Field object’s signatureValidate() method which returns a status code indicating the state of the signature field. In particular, the method returns 0 if the DigSig field is empty (hasn’t been signed) and 4 if the DigSig applied is valid and the identify of the signer was verified.

Note: This method cannot validate the status of an XML Data Signature which is different from a traditional DigSig.

Accessing the AcroForm Field Object

To access the AcroForm Field object that represents the XFA DigSig field in your form, you have to use the AcroForm Doc object’s getField() method and give it the name of the field you’re looking for.

To access the Doc object, you simply need to access the property in any XFA event. This property is the Doc object. From there, you call getField() and you give it the name of the DigSig field as it’s defined in the AcroForm DOM. That’s the tricky part: Your field’s full name is its SOM expression (shown here for a DigSig field in a page subform named “PageSubform1”):


however its AcroForm Field Name looks like this:


Fortunately, I’ve already written some JavaScript that generates the above syntax: Copy and paste the script from my AcroForm Field Name Generator into your event and all you have to do in your script is call GetFQSOMExp(DigSigField) where “DigSigField” is the XFA DigSig field whose AcroForm Field name you can to get.

From there, you simply make a call to the signatureValidate() method:

var status =;

switch (status)
    case 0:
    case 1:
        // not signed...

    case 2:
        // invalid signature...

    case 3:
        // valid but identity of signer cannot be verified...

    case 4:
        // valid signature...

        // error -- unexpected status code

PreSign and PostSign Events

A key component to making this work is the ability to verify the status of the signature after the user has interacted with the DigSig field. You may think of using either the Click or MouseUp events on the DigSig field however there’s a bug in Acrobat/Reader 9 (and older) that prevents the Click and MouseUp events from coming through if the user successfully applies a signature (if they cancel-out of the digital signature dialog that appears when they click in the DigSig field, the events fire but not if they apply a signature).

Fortunately, XFA 2.8 includes new PreSign and PostSign events which occur just before and immediately after clicking on the DigSig field and they behave correctly. The only drawback here is that they are only available for scripting in Designer 8.2 and only work in Acrobat/Reader 9 or greater.

Note that if you wanted to check for signature status on start-up, the DocReady event is the correct place to do it. Initialize, FormReady and LayoutReady events are too soon in the initialization sequence for signature status to be available.

Sample Form

Getting back to our use case where we want to show the submit button only once the user has signed the form, you would simply script the DigSig field’s PreSign event to show the button and then the PostSign event to check the status of the signature. If it’s not valid (the user didn’t apply a signature or there’s something wrong with the signature that was applied), you would then hide the submit button again.

The reason why you would show the submit button in PreSign and hide it again in PostSign is because showing the button in PostSign after applying a good signature would invalidate the signature’s status (the status would become “unknown”) because the form would be modified after signing. By showing the button after signing when it was hidden prior to it, the form would no longer be the state in which it was when it was signed (which is one reason for DigSigs in the first place — to ensure that the document is in the same state as which it was when the user signed it, otherwise the document may have been maliciously modified between the time when the user signed it and the time at which you received it).

Download sample [pdf]

(Note that you’ll need a digital ID to run the sample; if you don’t, you can easily create one in the digital signature dialog that appears when you click on the DigSig field.)

Sample Minimum Requirements: Designer 8.2, Acrobat 9.0

Posted by Stefan Cameron on November 5th, 2008
Filed under Acrobat,Bugs,Scripting,Tutorials,XFA

Bug: Cannot Clear Radio Button List Selection


Normally, setting a field’s rawValue property to null essentially clears its value. It should follow that setting a radio button list’s rawValue property would clear its selection (i.e. if one of its radio buttons was selected, none would be selected when its value is set to null).

To clear a text field, for example, you would do the following:

MyTextField.rawValue = null;

To clear a radio button list, the following should also work:

MyRadioButtonList.rawValue = null;

The issue is that the above statement for clearing a radio button list doesn’t work: The selection remains and the radio button list’s rawValue property remains set to the value of the selected radio button.


There are two workarounds to this issue. The first consists of clearing the data node associated with the radio button list, provided the radio button list is bound to data (which means the “Object palette > Binding tab > Default Binding property” is set to something other than “None”):

MyRadioButtonList.dataNode.isNull = 1;

Note that if you attempt to use this workaround when the radio button list is not bound to data, an error will occur because its dataNode property will be null and you’ll attempt to access the isNull property of a null object.

The second workaround consists of using the method to clear the radio button list:;

The advantage of the second workaround is that it will work regardless of whether the radio button list has a data binding or not.


Please refer to the Bug List for updated information on the version(s) affected by this bug as well as if and when it was/will be fixed.

Posted by Stefan Cameron on October 9th, 2008
Filed under Acrobat,Bugs,Scripting,XFA