Tag: Prince

Floating Field Fun

Floating fields in Adobe LiveCycle Designer allow you to create text in a form that contains variables such that the text wraps around these variables according to the length of the variable text. Using them is mostly straightforward in situations where they aren’t expected to change as a result of form interactions. If you do, however, the solution is less obvious.

The examples shown below were done in Adobe LiveCycle Designer 8.2.

The Scenario

  1. We have a ‘legal’ document that is created, as in a LiveCycle process, that contains boilerplate text which is a combination of static and dynamic information like the user’s name and a corporate name.
  2. We’d like the boilerplate text to dynamically size itself around the dynamic portions to account for different length names.
  3. We also have a few editable fields in another portion of the form, which also includes the users name. If a user needs to modify their name, we’d like the boilerplate text to update itself as well. One of our customers might be Prince, as in ‘The Artist Formerly Known As Prince’.  We honestly don’t know what his legal name is at any given time, so we’ll allow him to change this as needed.

These aren’t unusual requirements, nor do they seem at first glance difficult to achieve.

  1. If the floating field hasn’t already been created, we’ll do that first in the appropriate location of the form. No problem.

    Floating Field Creation

    Floating Field Creation

  2. Next, we’ll add some JavaScript to the initalize event of this floating field(‘floatName1’) and set its value to that of the matching field that has been merged. No problem.
    this.rawValue = subMatchingField.txtName.rawValue;
  3. We’ll define the value for the corporate name as a script element on the form itself. No problem.

    Storing a variable in a script object

    Storing a variable in a script object

  4. Now, let’s test that if the user updates the editable field, the floating field would update as well. Problem. Changing the Name from ‘Prince’ to ‘Prince Rogers Nelson’ did not also update the boilerplate text.

    Changing the name does not update the floating field

    Changing the name does not update the floating field

Once the form is rendered in the client( Reader, Acrobat, etc.), some trickery is required if we need modify a floting field in conjunction with an interactive event.

How do we do this?

There are at least 2 different ways I have discovered:

1.Force a Form Re-layout

Below, is the same script we had used in step 4 above. Only now, we are invoking xfa.layout.relayout() prior to updating the field. This forces the form to go through the layout process again, and will now be able to adjust the floating field.

xfa.layout.relayout();
subBoilerPlate.floatName1.rawValue = subMatchingField.txtName.rawValue;

2. Modify the floating field on the layout:ready event

While this works, I can’t recommend this approach several reasons.

  • Firstly, the event fires quite often when working with an interactive form, so this script will be executed quite often, not just when the specific field in question is updated. Recall that the layout:ready event fires as a result of any ‘substantial’ changes on the entire form, not just the field we have attached the script to.
  • Secondly, I discovered something quite interesting that I don’t know if it is a feature or a bug.  In either case, I don’t quite understand it, so can’t recommend it. It turns out that setting the value of the floating field to equal the matching name field on the layout:ready event instead of the initialize event doesn’t work for the reasons I thought it would .  In fact, if I leave my script to fire on the initialize event of the floating field and then add even something as trivial as a commented line of code in the layout:ready event on any field, the floating field will again update as we want it to.  It’s as though just going through the effort of trying to interpret any script during the layout:ready event is enough time to allow the update to happen.  To me, that doesn’t feel trustworthy. If anyone can explain this better, please leave a comment.

Summary / Sample

The attached XDP file below demonstrates the situation described above and how we might address it.

For ease of demonstration, I have two buttons on the form to attempt to trigger the update in the boilerplate text section as well as to update another text field. This allows you to see how the floating field behaves differently. In a real world scenario, you might actually see the script on the exit event of the field ‘txName’.

The first button will attempt to to the update without using xfa.layout.relayout() whereas the second button does.

Hope this helps — good luck!

Download Sample:  Floating Field