Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

'Bugs' Category Archive

Bug: "Page n of m" Custom Object Broken in Tables

Description

If you use the “Page n of m” object from the Library palette’s Custom tab, you may have noticed a bug when you drag that object from the Library directly into a table cell:

Canvas.gif

In the image above, the “Page n of m” object circled in green is correct whereas the one circled in red is not.

If you preview the form or run it in stand-alone Acrobat, you’ll get something like this:

Preview.gif

You can see, in the image above, that the green-circled object is showing the correct page information while the red-circled one isn’t showing any information at all. That’s because the text object from red-circled “Page n of m” object contains broken references to the Floating Fields which are used to display the current page and page count information.

Workaround

The “Page n of m” is a special object that’s actually made-up of 3 separate fields:

  • A hidden floating numeric field named “CurrentPage” which displays the current page’s number.
  • A hidden floating numeric field named “PageCount” which displays the total number of pages.
  • A text object which references both the CurrentPage and PageCount fields and has the text “Page # of ##”.

Hierarchy.gif

The image above shows how the red- and green-circled objects in the first image are represented in the Hierarchy palette which clearly shows that each “Page n of m” object is a hybrid object made-up of 3 separate objects.

The “Page n of m” works by using what Designer calls Floating Fields where a field (such as CurrentPage) is referenced by another object’s text. In theory, that would mean that you should be able to place floating fields in captions as well as in text objects however Designer only supports them in text objects.

If you use the XML Source tab to look at the source for the green-circled object, you’ll see how this is done (please note that I’ve abbreviated it here for clarity):

<field name="CurrentPage" presence="hidden" access="readOnly"
      id="floatingField011478"/>
<field name="PageCount" presence="hidden" access="readOnly"
      id="floatingField029358"/>
<draw name="Pages">
  <ui><textEdit/></ui>
  <value>
    <exData>
      <body>
        <p>
          Page <span xfa:embed="#floatingField011478"/> of
          <span xfa:embed="#floatingField029358"/>
        </p>
      </body>
    </exData>
  </value>
</draw>

In the above XML source, you can see that the text object (named “Pages”) has valid references to the CurrentPage and PageCount fields because its “xfa:embed” tags use their pertaining IDs.

If we now look at the XML source for the red-circled (broken) “Page n of m” object, it’s clear that the text object’s references to the CurrentPage and PageCount fields are broken since the IDs used by the Page text object don’t match those assigned to the CurrentPage and PageCount hidden Floating Fields:

<subform>
  <field name="CurrentPage" presence="hidden" access="readOnly"
      id="floatingField025864_copy1_copy1_copy1"/>
  <field name="PageCount" presence="hidden" access="readOnly"
      id="floatingField015020_copy1_copy1_copy1"/>
  <draw name="Pages">
    <ui><textEdit/></ui>
    <value>
      <exData>
        <body>
          <p>
            Page <span xfa:embed="floatingField025864"/> of
            <span xfa:embed="floatingField015020"/>
          </p>
        </body>
      </exData>
    </value>
  </draw>
</subform>

This can be easily fixed by modifying the IDs of the CurrentPage and PageCount fields to be the ones that the Page text object is expecting them to be: floatingField025864 and floatingField015020, respectively. Once you’ve fixed the IDs, previewing the form should give you something like:

FixedPreview.gif

You can see now that the once-broken “Page n of m” object in the table cell is functioning properly.

Fix

Please refer to the Bug List for updated information on the version(s) affected by this bug as well as if and when it was/will be fixed.


Posted by Stefan Cameron on September 6th, 2006
Filed under Bugs,Designer

Bug: Cannot Override Calculations

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:

  1. 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.
  2. 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.

Workaround

You could use two fields and a check box where the first field is simply “Calculated – Read Only” and the second field is the override value and is invisible until the check box is checked.

All calculations which depend on the calculated field in question would need to verify the value of the “override” check box: If it’s unchecked, calculations would use the value from the first field which itself may be calculated. If it’s checked, they would use the value from the second field which contains the override value.

Checking the check box would cause the first (calculated) field to become invisible and the second (override) field to become visible. You could even display an Override Message when the check box gets checked and use the

xfa.host.response("Question", "Title", "Default Value")

statement to give the user the option to cancel the override (the return value is null if the user picked the Cancel button).

Fix

Please refer to the Bug List for updated information on the version(s) affected by this bug as well as if and when it was/will be fixed.


Posted by Stefan Cameron on August 29th, 2006
Filed under Acrobat,Bugs

The Bug List Goes Live!

Some of you may have noticed the new Bug List 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, 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.


Posted by Stefan Cameron on August 25th, 2006
Filed under Bugs