It was recently brought to my attention that the web service used by my sample form for my tutorial on connecting a form to a web service is no longer operational. Obviously, that makes the sample form much less useful so I have posted a second sample form that uses a different web service. If you have been struggling with the original sample, please have a look at the new one I posted in an update to the original post.

The LiveCycle ES2 SP1 update is now available and includes an update to LiveCycle Designer ES2.

There is a new version of Adobe LiveCycle Café, renamed Adobe Enterprise Café, available for download. The new version lets you “aggregate content related to Adobe LiveCycle ES (Enterprise Suite), Acrobat, Connect, ColdFusion, and the Adobe Flash Platform in a timely and customized fashion.”

If you haven’t tried this out yet, it’s a great knowledge tool that lets you search across the entire Adobe Developer Community and Adobe DevNet resources, as well as get news updates, feeds, online training, events, etc., all in a single Adobe AIR application. You can even chat with other Adobe Developers who are online.

Did you know that the list portion of a drop down list field can be displayed programmatically? You can set focus to the field and force its drop list to be displayed all in a single API call:

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…

My friends at Avoka have posted a very useful tutorial on the unexpected behavior of borders in flowed layouts and how to use margins to fix it. Check it out!

Just a quick note to make you aware that while I may not be posting very frequently for the time being, I am still actively responding to your questions via comments.

Excerpts of the 10 most recent comments are now conveniently located directly on the home page, in case you want to see the latest activity.

Many of you have been requesting some debugging features for XFA Forms (and I’m sure many more of you just haven’t voted for it yet). It so happens that Acrobat Pro has a JavaScript Debugger which can be used — to a limited extent — with XFA Forms. See John Brinkman’s post to learn more about it — thanks John!

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!

Paul Guerette, a colleague of mine at Adobe, will be giving a “tech talk” eSeminar on connecting forms to databases over at AcrobatUsers.com on Tuesday, March 23, 2010, at 10am PST (1pm EST).

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!

I thought I would point-out a nice improvement that was made to XFA <subform> elements back in XFA 2.8: The addition of the access property.

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"

Did you know you could quickly access the Preview tab in the Form Properties dialog from the PDF Preview tab’s context menu?

My friend Angie Okamoto (Easel Solutions) was the one who originally pointed this out to me. It’s incredibly useful, especially when you’re switching between various preview data files (or options like interactive vs non-interactive), because it loads the dialog and activates the Preview tab in a single step. This saves both mouse travel time and one click which adds-up to a lot, if you do this frequently.

Right-click on the PDF Preview tab to get the context menu:

Choose “Form Properties” and you’re right on the Preview tab:

Another option is to set a Shortcut Key for the Form Properties dialog, though this won’t auto-select the Preview tab (but still saves some mouse travel and a couple of clicks). You can do this via the “Tools > Keyboard Shortcuts” dialog:

Unfortunately, I don’t recall what version of Designer introduced the PDF Preview tab’s context menu nor which one added Keyboard Shortcuts but I think both should be available since version 8.0.