Back when I announced that Designer 8.2 and Acrobat 9 had shipped, I mentioned that there had been a “major tab ordering UI update”. The Team knew that something had to be done to address all the issues you had been experiencing (it follows that it was the most requested feature on my Designer 8.2 Featur-O-meter) and I think they really delivered!

Make it so

I think one of the most significant improvements to the functionality is that what you set in Designer is what you get in Acrobat. In the past, given certain circumstances, the order you set in Designer was not necessarily the order you would get in Acrobat. Designer 8.2 and Acrobat/Reader 9, together, fix that issue.

For example, this view shows the new Tab Order palette where tab order is set to “Automatic” which means the order depends largely on the visual placement of fields on the form, from left to right and top to bottom:

In this next view, I’ve simply moved the City field below the Country field. As you can see in the tab order list, City is now last in tab order simply because it’s positioned below the Country field (and it’s also highlighted in the list because I have it selected on the canvas):

Tab Order palette

The Tab Order palette is how you work with tab order in Designer 8.2. While there is still a “tab order mode”, you no longer (attempt to) set the order by entering tab order mode and clicking on fields on the canvas in the order you want tab order to be set. Instead, you do everything from the palette (sequence numbers are still displayed over the fields and you can still click on them to select their corresponding item in the tab order list within the Tab Order palette but the order itself is no longer set by clicking on the canvas).

Before we go any further, there’s some extra visual aids for tab order which you’ll want to turn-on (if anything, they’re really cool). In the “Tools menu > Options command > Tab Order tab”, set the “Display Additional Visual Aids for Tab Order” setting:

Now select the Tab Order palette (“Window menu > Tab Order command”) and you’ll automatically be entered into “tab order mode” (if not, click on the “Show Order” button on the palette):

Once this is done, set the order to “Custom” so that you can set the order you want.

To get a feel for what the order is (now that you’ve enabled the “additional visual aids”), you can simply mouse-over the fields on the canvas:

(In the above screen shot, my mouse is hovering over the City field.)

Setting the order

Using the object list in the Tab Order palette, the order can be set in many different ways:

• drag and drop the items in the list
• multi-select items in the list and drag & drop them
• make a selection and use the arrow buttons to move them around
• select one item and hit the F2 key to manually set its sequence number
• make a selection (either with the mouse or the keyboard) and change the order by holding the Control key while using the up/down arrow keys
• cut and paste a selection using the items in the palette menu

Form Fragments

The Tab Order feature also handles form fragments gracefully and treats them as “white blocks”. Following my address block example, if you make a fragment out of the City, State and Zip fields, that object is now treated as a single object. The tab order can’t be changed from the reference to the fragment (i.e. the tab order of the fields inside the fragment can’t be changed from the form that references the fragment) but it can be changed around it:

In order to change the tab order inside the fragment, you’ll need to edit the tab order in the fragment itself.

Text Objects

Finally, the revamped Tab Order feature is also capable of handling text objects. This comes in handy especially when you have a hyperlink somewhere in a text object and you want to control where, in the tabbing sequence, that focus jumps to the hyperlink and where it goes to afterward.

In order to set the tab order of a text object, you must uncheck the “Tools > Options > Tab Order > Only Show Tab Order for Fields” option in the Tab Order Properties Dialog (checked in the linked screenshot: you must uncheck it).

After applying the above setting, the Tab Order Palette will show all form objects, not just fields.

Apr 3, 2010 — Added “Text Objects” section

---

Posted by Stefan Cameron on September 22nd, 2008
Filed under Acrobat,Bugs,Designer,Form Fragments,Tutorials

---

In the past, I’ve written a lot of articles on submitting data to databases and web services but there’s another way to submit form data: via HTTP POST. In this scenario, you use a regular button object configured to submit to a web page via HTTP or you just use the HTTP submit button object and set the URL appropriately.

Steve, a colleague of mine who works on LiveCycle Designer ES, wrote two posts about this technique a while back. I’ve frequently referred to it in my replies to your comments on various posts so I thought I would include the links in a more prominent place so they’re easier to find:

1. The original HTTP Submit post.
2. An important update to the original post.

One use of this could be to make submitting data to a database more secure* than exposing the database on the Internet (which is seldom a good idea). For example, you could have your form’s data posted to a PHP page which could then relay it into a MySQL database running behind the scenes. Another popular combination is ASP and Microsoft Access databases.

* Please note that I cannot speak to the level of security of said suggestion/solution. I’m merely suggesting it could be more secure.

---

Posted by Stefan Cameron on September 15th, 2008
Filed under Bugs,Data Binding,Designer,Tutorials

---

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

---