Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

'Debugging' Category Archive

Careful with Form Compatibility Settings

Let me put it simply: I got burned by using a particular syntax to check the existence of a field inside a subform object due to form compatibility settings in LiveCycle Designer 8.2.

What?

It started with a form I had created using Designer 8.1 which was set to target Acrobat 8.1/XFA 2.6. Later-on, I installed Designer 8.2 and wanted to update my form to target Acrobat 9/XFA 2.8.

In my form, I had a script object with various functions that used the following syntax to test the existence of a field inside a subform object which was passed-in to these functions as a parameter:

if (subformObj.someField)

The result of this was what I expected: If ‘someField’ existed inside ‘subformObj’, the IF statement would evaluate to ‘true’; if it didn’t, it would evaluate to ‘false’. According to the rules of dynamic properties in JavaScript, this was all fine and dandy.

Continue reading…


Posted by Stefan Cameron on February 11th, 2009
Filed under Acrobat,Debugging,Designer,Scripting,XFA

MAX 2008 Tutorial – Part 3 – Form Guide

Welcome to the third and final part of a three-part post series tutorial on importing data into a form guide and a PDF. The first part covered the form design, the second part covered the Flex code and the third part will cover designing and debugging the form guide that will complete the solution.

Form Guide Layout

The goal is to design a form guide which will provide two panels: one for user options and the other for results.

The first panel will expose the 4 fields inside the GuideObjects subform (which are only meant to be exposed in the form guide — hence why the GuideObjects subform has the Initialize script to hide it if the host isn’t “Flash”). The user will have the option to choose an actor and/or category for further filtering and will then click on the GetMovies button to execute the request on the Movie Service. When the requested XML is returned to the form guide, the GetMovies result handler will convert the XML into instances of MovieRow inside the Listing table.

The second panel will use a repeater layout to expose the Listing table’s contents within the form guide however this panel will only be accessible if the movie query returned 1 or more results.

Once the results are in, the user will then be able to switch (“flip”) to the PDF view which will show the Listing table in the form, from which the user could then print or archive the results.

Continue reading…


Posted by Stefan Cameron on November 19th, 2008
Filed under Acrobat,Bugs,Conferences,Debugging,Form Guides,Scripting,Tables,Tutorials

Target Version Reference

LC Designer ES (8.1) introduced a new feature called Target Version to help you design forms for use in specific versions of Acrobat/Reader. Although new releases of Designer usually support most new features introduced in new releases of Acrobat, there are still some differences and the Target Version feature will help you ensure that your form isn’t using a feature that isn’t compatible with the version of Acrobat/Reader that you’re targeting (the version you expect the users of your form to use).

You can set a form’s target version by using the “File menu > Form Properties > Defaults > Target Version” property.

For example, the “Lock Fields After Signing” feature of digital signature fields is not supported in versions of Acrobat/Reader less than 8.0. By setting your form’s target version to “Acrobat/Reader 7.0.5 or later”, Designer would issue a warning (in the Warnings palette) about this fact if you placed a digital signature field on your form and checked the “Object palette > Document Signature > Lock Fields after Signing” box.

The Target Version Reference document (under the “Develop” tab) details the versions of Acrobat/Reader that are compatible with Designer features from version 6.0 to 8.1, incl. This should help you ensure that your forms are always compatible with the versions of Acrobat/Reader you expect your target audience to use.


Posted by Stefan Cameron on April 18th, 2008
Filed under Acrobat,Debugging,Designer

Adobe Unveils LiveCycle ES

Today, Adobe unveiled its new LiveCycle Enterprise Suite. It includes a whole slew of new product versions all designed to work together in an IDE (Integrated Development Environment), bringing PDF and Flash together in the same workflow using a new technology called Form Guides (see the Generate dynamic Adobe Flash® Player compatible form guides topic in the LC Forms ES feature list). Form Guides enable you to add an RIA (Rich Internet Application) view to your form to engage your customers in a more compelling way.

What’s more is that the new Enterprise Suite launch means that there’s also new version of Designer: LiveCycle Designer ES (version 8.1). I believe this will be an upgrade to Designer 8.0 which currently ships with Acrobat Pro 8.0. Most notable in this new version are

  • the new Guide Builder tool which will help you quickly re-purpose your PDF form as a Flash-based Form Guide;
  • a new feature called Form Fragments which will enable you to re-use sections of your forms and scripts in other forms while only needing to make changes in one place;
  • a Syntax Checker in the Script Editor to check for errors in your scripts (this will definitely help with debugging!); and
  • the Target Validation feature which will help you determine which XFA features you may use when targeting a specific version of Reader/Acrobat (e.g. if you specify Reader/Acrobat 7.0 as your target version and you insert a table into your form, you’ll get a warning telling you that tables aren’t supported in Reader/Acrobat 7.0 — they’re only supported as of Reader/Acrobat 7.0.5).

Posted by Stefan Cameron on June 4th, 2007
Filed under Debugging,Designer,FormCalc,Scripting

Previewing as Dynamic PDF

Have you ever lived through the frustration of previewing a form on which you’ve written a simple little script to affect the presence of an object when a button is clicked and pulling your hair out because you keep clicking on the button and nothing happens (object doesn’t disappear, there’s no error message, etc.)? Or maybe you’ve been in a situation where you’ve added script to a button in order to insert a new instance of a repeatable subform and while clicking on the button doesn’t produce one, the submitted XML data file contains entries for each new instance that was added?

Even if you haven’t, it may happen someday so here’s the remedy for the case of the “Common (Static PDF) Flue”…

In Designer, there are two different locations containing settings which affect the type of temporary PDF file created when you click on the Preview tab:

  1. Under the “File Options” section within the “Document Handling” panel of the “Tools | Options” dialog, you can set the Default File Type for New Forms. This type is used on new forms which you preview prior to saving (because Designer doesn’t know which format you’ll use at the time of preview). This is set to a static PDF format by default.
  2. Even if you’ve specified a dynamic PDF format for the Default File Type for New Forms, this setting may be overridden by the Preview Type and XDP Preview Format properties in the “File | Form Properties” dialog in the “Defaults” panel once you’ve saved your form. The Preview Type property, set to “Interactive” by default, determines whether the form will be previewed as an interactive (dynamic) form or as a print (static) form. This property supersedes the PDF format. The XDP Preview Format property usually picks-up the Default File Type for New Forms setting and determines what PDF format will be used to preview your form should it be saved as an XDP. (Note that if you’ve saved your form as a PDF file, then the XDP Preview Format setting is ignored).

Now that we’ve covered the different properties which affect the PDF preview format, here’s how to kick that flue I was talking about earlier (so that you actually do preview in a dynamic PDF format and stop pulling your hair out):

  1. If you haven’t saved your form, make sure the Preview Type is set to “Interactive” and that the Default File Type for New Forms is set to a dynamic PDF format. You may also want to set the XDP Preview Format to a dynamic PDF format while you’re at it.
  2. If you’ve saved your form as a dynamic PDF, make sure the Preview Type is set to “Interactive”.
  3. If you’ve saved your form as a static PDF, none of these settings will help you. You must first save your form as a dynamic PDF.
  4. If you’ve saved your form as an XDP, make sure the Preview Type is set to “Interactive” and the XDP Preview Format is set to a dynamic PDF format.
  5. If you’re tired of running into these problems and want to avoid them in the future, just set your Default File Type for New Forms to a dynamic PDF format.

I hope this tip improves your form design health. It did wonders for me!

Updated: January 27, 2007


Posted by Stefan Cameron on July 24th, 2006
Filed under Debugging,Designer,Scripting