Archive for August, 2006

Bug: Cannot Override Calculations

h2. Description

The XFA language supports fields which are calculated yet still overridable by the person filling the form. For instance, you may have an invoice on which you calculate the tax associated with a purchase using a calculated field yet, for customers from other countries, you would like to allow them to override the calculated tax amount and enter the correct amount themselves.

To do this, you would use the Object palette’s Value tab and set the field’s Type property to _Calculated – User Can Override_. You could even go as far as specifying an Override Message which would appear if the user attempted to override the field’s calculated value.

In theory, when the user attempts to override the field’s calculated value, either the Override Message or, if none was specified, an Acrobat default message appears warning that the field is calculated and gives the user the option to continue with the override or to cancel. If the user proceeds with the override, subsequent calculations use the override value instead of the original calculated value regardless of subsequent changes to other fields which the overridden field’s calculations were dependent on.

Unfortunately, there’s a bug in Acrobat that causes the overridden value to be discarded. It manifests itself in a couple of different ways:

# *Dynamic PDF:* Not only will the value specified by the user (the override) not be retained but the Override Message (if specified) won’t be displayed. The behavior is simply to let the user type-in a value but then throw it away and run the calculation again without any warning.
# *Static PDF:* In this case, the Override Message (if specified) is displayed and the user has the option to discard their change or proceed with the override but the specified value is discarded regardless of what they choose to do and the calculation is run again.

Continue reading…

The Bug List Goes Live!

Some of you may have noticed the new “Bug List”:http://blogs.adobe.com/formbuilder/buglist.html side bar module on my blog recently. I’m excited to launch this new section of my blog tonight and I hope that it’ll add even more value to your visits here as well as to your experience using Designer and Acrobat to design and develop your electronic forms.

Look for a few kick-off posts in the coming days about some bugs that fellow readers and users have reported as well as some that I’ve come across myself while making the various samples I’ve already posted to this blog. Of course, I there shouldn’t be any in the features I worked on… ;)

My hope for this new section is that it’ll serve as a reference for things to watch-out for in the versions of Designer and/or Acrobat that you may be using as well as what to do in order to get around them.

Complex Validations

A couple of days ago, Michael Ramirez “asked me”:http://blogs.adobe.com/formbuilder/2006/08/invalid_flashing_fields_2.html#comments how to do complex validations on forms. He asked how one could have a validation as follows: Given 3 text fields A, B and C and a check box E, A is mandatory only if B and C are filled or if E is checked. I thought this would make a great little sample of both complex validation scripts and what I like to call the “Two Button Submit” technique.

“Download Sample [pdf]“:http://blogs.adobe.com/formbuilder/samples/ComplexValidations.pdf

*Minimum Requirements:* Designer 7.x, Acrobat 7.x.

Continue reading…

Invalid Flashing Fields 2.0

A colleague of mine here at Adobe pointed-out today that the use of the AcroForm Document object’s _getField_ method wasn’t necessary in the script I used for my original “Invalid Flashing Fields”:http://blogs.adobe.com/formbuilder/2006/06/invalid_flashing_fields.html sample.

There’s an alternative which uses _xfa.form.resolveNode_ in the _app.setInterval_ script. _xfa.form.resolveNode_ takes a SOM Expression and returns a reference to an XFA node. What’s more is that this API call can be made from within the context of the “AcroForm”:http://blogs.adobe.com/formbuilder/2006/06/acroform_objects.html Scripting Object Model.

The _app.setInterval_ script therefore changes from this:

bc. moFlashTimerID = app.setInterval(
“var f = ==== this.getField(‘” +
GetAcroFormFieldName(oField) + “‘); ==
== ” +
“if (color.equal(f.fillColor, color.red))” +
“{ f.fillColor = [" + moAcroFieldFillColor.toString() + "]; }” +
“else” +
“{ f.fillColor = color.red; }”,
500);

to this:

bc. moFlashTimerID = app.setInterval(
“var f = ==== xfa.form.resolveNode(‘” +
oField.somExpression + “‘); ==
== ” +
“if (f.ui.oneOfChild.border.fill.color.value == ‘255,0,0’)” +
“{ f.ui.oneOfChild.border.fill.color.value = ‘232,232,232’; }” +
“else” +
“{ f.ui.oneOfChild.border.fill.color.value = ‘255,0,0’; }”,
500);

Also note the changes in the way the color values are compared and assigned (whereby the newer version uses more familiar XFA script rather than the AcroForm script from the first version).

Since the use of the “AcroForm”:http://blogs.adobe.com/formbuilder/2006/06/acroform_objects.html Scripting Object Model should *always* be secondary to using the XFA Scripting Object Model (because AcroForm objects are, after all, in a separate Object Model which may change separately from the XFA Scripting Object Model), I wanted to highlight this alternative which makes more extensive use of the XFA Scripting Object Model than the first version did.

“Download Sample [pdf]“:http://blogs.adobe.com/formbuilder/samples/AcroFormObjects/InvalidFlashingFields-WithoutAFGetField.pdf

*Minimum Requirements:* Designer 7.1, Acrobat 7.0.5.

Importing Data in Acrobat

Data is central to every form. Some forms simply collect data while others use pre-collected data to do various things to forms, such as pre-populate names, phone numbers, addresses, affect the layout of a form or various other things.

Using pre-collected data to affect a form as described above involves *importing* data into a form via the host application (assuming a server isn’t part of the picture). This time around, I want to talk specifically about importing data using *Acrobat*.

As you all know, Adobe distributes the “Reader”:http://www.adobe.com/products/acrobat/readermain.html application for free. Because of this, you can save the forms you design in “Designer”:http://www.adobe.com/products/server/adobedesigner as PDF and anyone with the free Reader application can fill your form and submit its data electronically.

The catch is when your PDF form requires data to be imported. Unless the host application is “Acrobat Professional”:http://www.adobe.com/products/acrobatpro or “Acrobat Standard”:http://www.adobe.com/products/acrobatpro/acrobatstd.html, a _regular_ PDF form *cannot* import data — no matter if it comes from an XML Data file or from a data connection to an ODBC or WSDL data source. Acrobat Pro/Std comes with all the tools you need to import data into a form and permits data to be automatically imported via an ODBC or WSDL connection. PDF forms opened in Reader (or “Elements”:http://www.adobe.com/products/acrobatpro/acrobatel.html for that matter), on the other hand, aren’t privy to that functionality by default — that is, Reader 7.0.7+ (the latest version is 7.0.8) doesn’t allow data import by default.

In Reader 7.0.5, there was a bug that resulted in Reader having the ability to import data into forms. Unfortunately (well, that’s my opinion), that bug was fixed in Reader 7.0.7 such that Reader can no longer, by default, import data into a PDF form.

In general (at least as of Reader 7.0.7), PDF forms opened in Reader must be individually _extended_, using Acrobat Professional or “Adobe LiveCycle Reader Extensions”:http://www.adobe.com/products/server/readerextensions, to allow the use of “hidden” functionality in Reader (such as Data Import or Commenting). (You can reader-extend forms using Acrobat Professional’s “File | Form Data | Initiate Data File Collection Workflow” menu item in order to collect data via Reader for a limited number of submissions.)

Another option is to use “Adobe LiveCycle Forms”:http://www.adobe.com/products/server/formserver to deploy your forms. Using this server product, you can pre-populate forms with data _on the server_ prior to deploying them to the client application (on the user’s system). Using this option, you don’t need to reader-extend a PDF form which imports data because the data is imported and merged into the PDF form _on the server_ and then deployed to the client application (any version of Acrobat/Reader on the user’s system), which, in turn, doesn’t need to import any data.

To summarize, here’s a little table that illustrates the conditions under which you can import data into a PDF form in Acrobat:

_|((())). *Version* |((())). *PDF Form* |((())). *With Reader Extensions* |((())). *With LiveCycle Forms* |
|((())). Reader |((())). %{color:red} *no* % |((())). yes |((())). yes |
|((())). Elements |((())). %{color:red} *no* % |((())). yes |((())). yes |
|((())). Standard |((())). yes |((())). yes |((())). yes |
|((())). Professional |((())). yes |((())). yes |((())). yes |

====
~*Updated:* September 20, 2006~

Tracking Mouse Clicks

I just recently received another “comment from Zack”:http://blogs.adobe.com/formbuilder/2006/08/autolocalizing_your_forms.html#comment-18302. This time, he was wondering about how one would go about tracking mouse clicks on an image field.

I had never attempted to do that so I took it on as a challenge and thought I would share the results in this post.

I knew from the start that XFA alone wasn’t going to be able to handle this simply because (to my knowledge) it doesn’t provide any information as to the position of the mouse pointer when an event occurs. The most logical place I thought would’ve provided the information — the _Event Pseudo Model_ (the xfa.event object available in all XFA events) — didn’t live up to my expectations. Thankfully, XFA at least provides a Click event so that I could know when the image got clicked.

The next logical place to look was in Acrobat’s Scripting Object Model (in the “AcroForm Objects”:http://blogs.adobe.com/formbuilder/2006/06/acroform_objects.html). In the Acrobat Document object, I found what I was looking for: the _mouseX_ and _mouseY_ properties which provided the location of the mouse with respect to the document window.

The last thing I needed was information about the dimensions and location (within the Acrobat Document Object’s coordinate space) of the image field and the Acrobat Field object’s _rect_ property would give me just that.

The combination of the XFA Click event, the Acrobat Document object’s mouseX and mouseY properties and the Field object’s rect property was just what I needed to get this to work.

Of course, I soon discovered that I had another problem to figure-out: The behaviour of an image field in a PDF form running in Acrobat is that when clicked, it opens a browse dialog that lets you pick the content for the field. Unfortunately, there isn’t any way to suppress that dialog other than making the image field read-only or by using a static image object but then both alternatives prevent the Click event from firing. So I needed some clever way to capture a mouse click over an image (whether it was a field or a static object) and I decided to use a button with a transparent fill and no border (so it was essentially transparent). Since buttons are fields just like image fields, the mouseX, mouseY and rect properties would still be available for the button and if I sized the button to fit the image and placed it over-top, I would essentially end-up with an HTML <map>.

“Download Sample [pdf]“:http://blogs.adobe.com/formbuilder/samples/AcroFormObjects/TrackingMouseClicks.pdf

*Minimum Requirements:* Designer 7.1, Acrobat 7.0.5.

Continue reading…

Auto-Localizing Your Forms

A few days ago, I posted about Designer 7.1’s new “Dynamic Properties”:http://blogs.adobe.com/formbuilder/2006/07/dynamic_properties.html feature. In that post, I explained how this feature could be used to automatically populate a list box or drop down list field with data from a data connection without having to write any script.

Today, I thought I would highlight one of the *main advantages* to using this feature: *localization* of your forms!

By using the Dynamic Properties feature to bind the caption of form fields to data nodes in a data connection, you can easily localize your forms *without having to write any script*!

To illustrate how this would work, I’ve designed a simple little form which has an address block on it (taken from the “Address Block” custom object that ships with Designer, found under the Custom tab in the Library palette). Each field in the address block (which excludes the “Locale” field at the top that’s just there for informational purposes) has its Caption property bound to a specific data node in the data connection I’ve defined, based on some different localized XML Data files. To localize the form at run-time (e.g. in Acrobat), just open the form and then load the XML Data file pertaining to the locale you want to use.

“Download Sample [zip]“:http://blogs.adobe.com/formbuilder/samples/DataBinding/AutoLocalizedForm.zip

*Minimum Requirements:* Designer 7.1, Acrobat Pro 7.0.5.

*Note:* If you open the form in Acrobat, don’t forget to load a data file into it by using the options under the “File | Form Data” menu.

Continue reading…