The time has come for me to focus my extra energy on other goals and projects at Adobe and at home.

I have thoroughly enjoyed helping the XFA community for these past 4.5 years. All of the content on this blog was a direct result of your questions and I learned a great deal about Adobe’s XFA technology and its LiveCycle Enterprise Suite along the way. Thank you!

I leave you now with a final “form to end all forms” (in my mind, anyway): A version of the classic Tank Wars game implemented entirely in XFA + JavaScript.

Why do this, you wonder? Well, it was a good challenge, you couldn’t embed Flash in an XFA form back then and I wanted to do something that would really put LiveCycle Designer’s Script Editor through its usability paces.

Comments are now closed on all posts and pages except for this one and the XFA Tank Wars page which will close on December 31, 2010. I will continue to host this blog for your reference and bookmarks however I cannot guarantee it will be available forever.

Good luck on all your present and future form development projects.

Stefan

xfa.host.openList(@object)
xfa.host.openList(@string) -- deprecated since XFA 2.6

where @object is a reference to the drop down list field and @string is the SOM expression of the drop down list field.

xfa.host.openList(myDropDownList); // set focus/show the drop list

The second form of the API has been deprecated since XFA 2.6 which means that since Designer 8.1, it is preferred to use the first form which takes a reference to the field rather than its SOM expression.

If you’re using Designer 8.0 or earlier, you can get the SOM expression of any field by using its somExpression property:

xfa.host.openList(ddlInDesigner71.somExpression)

This works in both JavaScript and FormCalc with the same syntax.

Now if only there was a way to programmatically show the drop calendar of a date/time field…

As he puts it, there are limitations, the biggest ones of them being, in my opinion, the inability to debug script objects and the inability to retain breakpoints between debugging sessions. Nonetheless, this tool can give you way more insight than the good old “JavaScript Console + saveXML(‘pretty’)” combination can in certain cases, and it does it in a nice tree to boot!

If you have been struggling with connecting a form to a database, are wanting to know what the best practices and/or security concerns are, or have some specific questions you would like to ask, I highly recommend you attend the session. It’s free to attend (and free to become a member in order to attend)!

I’ll be answering chat questions “live” as the session unfolds. I hope you can join us!

In days of yore, if you wanted to disable all fields and exclusion groups (for the sake of brevity, I’ll refer to these collectively as “fields” in this article) in a particular section of your form, you would’ve had to write a script that recursively drilled down into all children of that section looking for fields to disable. This is because the access attribute only applied to fields.

With this change, assuming the section in question is contained within a subform, you can now easily disable all fields contained within it simply by setting the subform‘s access attribute to “readOnly”!

The following table describes the four levels of restrictiveness (in XFA 2.8, from the highest level to the lowest) that can be imposed on fields using the access attribute, either directly on a field or by a parent subform:

When a subform imposes restrictions on the fields it contains (meaning all fields within any level of nesting, not just immediate children), the inheritance on child fields and subforms follows that of the most restrictive parent imposition. For example, if a subform imposes access=”protected” and a child subform has access=”readOnly”, all of the inner subform’s children, including the inner subform itself, will effectively have a “protected” access level.

The explanations of the various access types in the table above are summarized. “Access Restrictions” on page 48 of the XFA 2.8 specification has more precise, albeit more technical, explanations of each level of restrictiveness.

Setting Access by Script

Setting the access attribute of a field or subform by script is simple, both in JavaScript and FormCalc:

// set access level to read-only:
FormObject.access = "readOnly";

If you wanted to disable all fields in the entire form with a single line of script, you would simply set the root subform’s access attribute to something other than “open”, as appropriate:

// if the root subform's name is "form1":
xfa.form.form1.access = "nonInteractive"

When editing the contents of a text object, pressing the [Enter] key will produce a paragraph break which means that any Above and/or Below Spacing you have specified will come into effect, amongst other paragraph formatting-related properties. Under the hood, the effect is the insertion of a “new line” character (\n) in a plain text object or a new <p> tag in a rich (XHTML) text object.

Sometimes, however, you need to break a line without producing a new paragraph. For example, you might have a long URL to insert and, given its position within the contents, it ends-up being broken onto another line and you would prefer to keep it on a single line, yet part of the same paragraph. To do this, use the [Shift + Enter] keyboard sequence. The result is a “soft” break to another line without moving to a new paragraph. Under the hood, this translates into the insertion of a U+2029 Unicode break character in plain text or a <br> tag in rich (XHTML) text.

Those of you using a version of Designer which precedes the 8.2.1 release should note that when using [Shift + Enter] in a plain text object, the contents of the object gets converted into rich text since previous versions of Designer would always use the <br> tag to denote a line break. Designer 8.2.1 coincided with the release of Acrobat/Reader 9.0 which provided improvements to the Text Engine in order to support the plain text U+2029 Unicode break character.

Line Breaks in Acrobat/Reader

What I describe above relates to the authoring experience in Designer. Inserting line breaks (as opposed to paragraph breaks) while filling a form in Acrobat/Reader is different. John Brinkman explains the “why and how” in this post.

Sample Form

Download Sample [pdf]

I have included a sample for that demonstrates the different types of breaks in both plain and rich text objects. I also included a text field that has a multi-line rich text caption (the contents of the rich text object) and a multi-line default value (the contents of the plain text object), both using paragraph and line breaks. (If you’re wondering how I got those values into the caption and default value properties, I used good old Copy & Paste in both cases.)

Minimum Sample Requirements: I authored this sample using Designer 8.2.1.2 and Acrobat 9.3. It should work back to Acrobat 9.0. I’m unsure of the results in earlier versions of Designer and Acrobat due to the use of the U+2029 character in plain text.

The service is quite simple: It displays what you submit to it. Since Designer’s “PDF Preview” tab is actually an instance of Internet Explorer hosting a PDF version of the form you’re previewing (a temporary PDF if your form is saved as an XDP or is new), the results are conveniently displayed within the tab itself after clicking on the submit button.

To use the service, simply use either an http submit button (or a regular button with its “Object palette > Field tab > Control Type property” set to “Submit”) and set its URL to:

http://forms.stefcameron.com/services/http-submit-test/

The idea is to use this service as a means to test/debug your forms before spending time writing the actual server code that will receive the data. You can also use it to ensure that you are submitting the correct data to a third-party service (for which you don’t control the server-side code).

Choosing a Submit Format

HTTP submissions can be made in various formats: XML, XDP, URL-encoded (HTTP post), and PDF. If you are using Reader instead of Acrobat, you will not be able to submit in PDF format unless you have enabled this ability using LC Reader Extensions.

The most important difference amongst the formats is that repeating data sets cannot be submitted using URL-encoding (HTTP post). This is due to the way the data is submitted: In HTTP post directives, data is submitted in “name=value” pairs. Since repeating data sets involve hierarchy and duplicate data node names, only the last instance of the repeating set will be submitted.

To submit repeating data sets, you must choose either XML, XDP or PDF as the data format.

Sample Form

The following sample form demonstrates the use of the HTTP Submit Test service.

Download Sample [pdf]

The form has a typical address block as well as a table to demonstrate both static and repeating data sets. Use the submit buttons to try submitting in different formats (XML, XDP, PDF, URL-encoded). Notice how only the last table row is submitted when using the URL-encoded (“post”) submit button.

Minimum Sample Requirements: I created this sample using Designer 9.0 and Acrobat 9.2 however it should work fine back to Acrobat 7.0.5.

Here’s a short list of what’s new in XFA 3.1:

• relational data support for data containing multiple tables related by keys;
• ability to bind to non-schema-defined elements (i.e. data injection into a schema data description);
• long or short edge duplexing; and
• support for more label printers, including Datamax Printer Language (DPL), Intermex Printer Language (IPL), and Tally Compressed Printer Language (TCPL).