The recent update to Acrobat/Reader 9.1 supports XFA 3.0. Unfortunately, the currently-shipping version of LiveCycle Designer (even with its update) won’t author/support more than XFA 2.8 until the next release. The comments for the XFA 3.0 spec indicate that “there will be releases [of LiveCycle Form Server and LiveCycle Designer] for XFA 3.1 and they will also handle 3.0.”
There are still some great things worth mentioning about XFA 3.0. In particular,
- new “inactive” value for the presence attribute which, when set on a container (e.g. subform), “prevents the container and its contents from processing calculations, validations, and events”;
- enhancements to events framework now permits event propagation upward to parent objects — this is great because you can now implement validation code on a subform for all of its children instead of having validation code in each child, for example;
- new validation events and global validation handling control — this should address a lot of the current issues with form validation.
It looks like John Brinkman will be detailing these new features, and perhaps others, soon.
August 18, 2009 — Added links to new XFA 3.0 topics on FormFeed.
Posted by Stefan Cameron on March 24th, 2009
Filed under
Acrobat,
Events,
XFA
Connecting to a web service usually means using import bindings to capture the response but what if you wanted to do something special with the response? What if the response wasn’t exactly correct for merging into your form (e.g. you just wanted to extract a part of the response and push it into your form somewhere)?
You could still use import bindings (set using the “Object palette > Bindings tab > Import/Export Bindings property”) but then you might have to hide most — or all — of those fields if you didn’t want to expose them. You would wait for the web service data connection to execute, then find the field that contains the piece of data you want and set it where it needs to go. This isn’t ideal, however, because Designer doesn’t expose any events, in the Script Editor, that would let you know that you now have data from the web service response in your form. Furthermore, having those extra fields around could add a lot of unnecessary weight (read: file size).
Continue reading…
Posted by Stefan Cameron on March 23rd, 2009
Filed under
Data Binding,
Designer,
Events,
Scripting,
Tutorials,
XFA
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:
- reduced performance when working in Designer;
- form file bloat (into the multiple MBs); and
- 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
I am certain at some point in time you have had to fill-out some type of form on a website and the required fields were identified by an asterisk (*). This is a common way to communicate to a user which fields are mandatory and which ones aren’t.
This is a design pattern that the Form Guide Team adopted when they conceived the default Form Guide user experience. Since the appearance of a field in a form guide doesn’t have to be the same as that of the field in the form (PDF), they were able to automatically add an asterisk next to mandatory fields without affecting their PDF counterparts.
Continue reading…
Posted by Stefan Cameron on March 16th, 2009
Filed under
Acrobat,
Form Guides,
Scripting,
Tutorials
In case you missed it, John Brinkman posted a great article on how to extract more information from a JavaScript exception (caught in a try/catch block). Have a look — there’s lots of useful information in the exception object and it’s just a matter of knowing how to expose it. It could save you hours of debugging time!
Posted by Stefan Cameron on March 13th, 2009
Filed under
Debugging,
Scripting
