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

---

Description

When changing a table’s column widths via the table object’s “columnWidths” attribute, the table’s columns will not be rendered correctly.

For example, consider the following table:

Clicking on the “Expand Columns” button sets the width of the first column to 2 inches and the width of the second column to 3 inches with the following script:

Table1.columnWidths = "2in 3in";

In Acrobat 8.0 or earlier, this is the result:

The problem is that the table’s layout hasn’t been properly updated after the changes to its column width attribute.

Workaround

Fortunately, there’s a simple workaround to this problem which consists in forcing an update to the layout after setting the column widths of a table:

Table1.columnWidths = "2in 3in";
xfa.layout.relayout();

Note that a lot of these table rendering issues have now been addressed in Acrobat/Reader 8.1.

When using the above workaround or Acrobat/Reader 8.1, this is the result you get:

Fix

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 June 13th, 2007
Filed under Acrobat, Bugs

---

Description

If an exception is thrown during a web service (WSDL) data connection request call (you’re executing a request to a web service in order to get a response in return), the bound data accumulated by Acrobat (for submitting the request to the web service) is not cleared from the data connection’s "request data buffer/queue" (to put it in simple terms).

For example, if your form attempts to execute a WSDL data connection while there is no active connection to the Internet, the call to the

xfa.connectionSet.WSDLConnectionName.execute

method will fail with an exception (which you can catch by placing the call within a try-catch block) however the form data accumulated to be sent as part of the request operation isn’t cleared. If you are then resetting the form by clearing repeatable subform instances that contained data at the time the data connection was executed and then re-execute the data connection, the old instance data will still be sent as part of the new request even though it’s no longer part of the form (which is clearly not what you would want/expect).

Workaround

Fortunately, you can manually clear the "request data buffer/queue", located in

xfa.datasets.connectionData.WSDLConnectionName

where "WSDLConnectionName" is the name of your WSDL data connection, simply by using the "remove" function as follows:

xfa.datasets.connectionData.WSDLConnectionName.remove();

Fix

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 May 5th, 2007
Filed under Acrobat, Bugs

---

Description

When executing a web service (WSDL) data connection, only the last instance of a repeatable element is included in the request.

Here’s an example of a repeatable WSDL element (the “Detail” element containing item number information):

<xsd:element name="Details">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element name="Detail" maxOccurs="unbounded">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="ItemNumber" type="xsd:string"/>
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>

The correct behaviour is that all instances of a repeatable section are used in the request sent to the web service.

Workaround

Unfortunately, there are no workarounds for this problem however the bug will be fixed in the next release of Acrobat.

Fix

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 May 2nd, 2007
Filed under Acrobat, Bugs

---

Description

Image objects (images and image fields) have a property which you can set to specify whether the image should be embedded or linked (the "Embed Image Data" check box on the Object palette’s Field tab).

When the property is checked, the result is that the image file loaded into the image object is embedded into the XFA Data that’s stored in the form. When the property is unchecked, only the URI (file path or URL) is stored in the XFA Data.

I put emphasis on XFA Data above because it’s important to understand the difference between the XFA layer and the PDF layer of a PDF form in order to understand what this bug is all about: Essentially, an XFA form saved as a PDF file results in a PDF container with the XFA inside (as opposed to saving the form as an XDP where the XFA form is at the top layer). When the PDF form is subsequently filled and saved within Acrobat (Standard or Pro), the image loaded into an image field object is supposed to be saved on one layer or the other depending on the setting of the "Embed Image Data" property on the image field.

When you save a PDF form in Acrobat, what gets saved in the XFA Data (in the XFA layer) depends on the value of the "Embed Image Data" property (which maps to the //field/ui/imageEdit@data attribute). If it’s set to "link" (unchecked), then only the original path to the image file is saved. If it’s set to "embed", then the image file is text-encoded and saved in the data instead of the original file path. In either case, however, the image should always be embedded into the PDF layer (don’t worry, it doesn’t actually get embedded twice, once on each layer, I’m just simplifying things a little here) such that the PDF is self-contained and can be re-distributed without having to ensure that the linked image file remains accessible from any location.

Unfortunately, there are cases when the image file doesn’t get embedded into the PDF layer when it should be. For example, if you have an image field object which is set to link to its image file and you load the image by importing data that contains the file path then save the PDF, the image won’t be embedded into the PDF as expected.

Workaround

At this time, I’m not aware of any workarounds to the specific issue I stated above (when importing the image’s file path).

The only way to consistently get image files to be embedded into the PDF as they should be — regardless of the image field object’s setting to link or embed its data — is to manually click on the image field object in Acrobat and pick the image file.

Fix

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.

Update (May 22, 2008)

This bug was addressed in Acrobat/Reader 8.1 (XFA 2.6, PDF 1.7) in a way that addresses both security and PDF self-containment issues.

For XFA 2.6+ forms (forms authored in Designer 8.1+), images that are linked (referenced) rather than being embedded are now stored (the bits are embedded) in an array in the PDF layer when the PDF form is saved. At runtime, if an image is linked (referenced) rather than embedded, Acrobat/Reader will look for the associated image bits in the PDF layer and, if a match is found, will load the image. This means that Acrobat/Reader no longer goes outside of the PDF to fetch images unless explicitly directed by the user (e.g. the user clicks on an image field and chooses an image on their own) which addresses security issues. The fact that linked images are now stored in the PDF layer also addresses self-containment issues where the nature of a PDF document is that it is a self-contained entity (e.g. when you email a PDF, the recipient can always open it and see its content even if they don’t have access to referenced content — the exception being if the form makes an external data connection to a database or web service or needs an XML data file to be imported).

Image fields with content embedded at design time are still stored in the XFA data as they were before. You may still load an image dynamically from data provided that the data is the actual image bits or, if the data is a link, that there are associated image bits already in the PDF layer (which implies that the image was linked from the form at design-time — for example, you could have 5 hidden image objects each linking to different images and then use a link in the data to control which of those images show up in an image field on your form). In either case (whether the image is loaded via embedded bits or a link), the image bits always end-up in the data submitted from the form. The original link is not included in the submitted data nor is it available at runtime via scripting (unless imported in data via a data connection or XML data file) because it could contain sensitive information (e.g. your username).

---

Posted by Stefan Cameron on January 23rd, 2007
Filed under Acrobat, Bugs

---