Editable Floating Fields V2

This is a follow-up to a previous blog entry that you probably should read first.

After doing the first version of the floating field editor, I tackled some issues/enhancements:

  1. A bug in the script where if you tabbed out and tabbed back in, the editor stopped working.
  2. Enforce constraints associated with the referenced fields
  3. When the editor does not have focus, display the field values using the formatted values of the referenced fields
  4. When the editor has focus, display the field values using the edit values of the referenced fields

I have updated the previous sample form — as well as the Editor fragment.

Enforcing Field Constraints

Since the floating fields are all presented inside a single text field, there was originally no constraints on any of the user input.  Now the form will look at the referenced fields and will restrict user input:

  • Respect the max chars constraint of text fields (in the sample, they’re all limited to 10 characters)
  • For numeric fields, limit input to valid numeric characters
  • For choice list fields, limit input to the set of valid choices

Locale-sensitive Numeric Fields

When restricting the set of valid characters for numeric input, it is tempting to just go with the obvious set:
[0-9\-\.]  However for many locales, the radix (decimal) and minus symbols will be different.  In order to know which symbols to use, the form queries the locale definition.  You XML source peepers will be aware of the <localeSet> packet in your XDP files.  This has all the data for the locales that are explicitly referenced on the form. 

The symbols are stored in a format that looks like:

<localeSet xmlns="http://www.xfa.org/schema/xfa-locale-set/2.6/">
   <locale name="de_DE" desc="German (Germany)">
      <calendarSymbols name="gregorian"> … </calendarSymbols>
      <datePatterns> … </datePatterns>
      <timePatterns> … </timePatterns>
      <dateTimeSymbols>GjMtkHmsSEDFwWahKzZ</dateTimeSymbols>
      <numberPatterns> … </numberPatterns>
      <numberSymbols>
         <numberSymbol name="decimal">,</numberSymbol>
         <numberSymbol name="grouping">.</numberSymbol>
         <numberSymbol name="percent">%</numberSymbol>
         <numberSymbol name="minus">-</numberSymbol>
         <numberSymbol name="zero">0</numberSymbol>
      </numberSymbols>
      <currencySymbols> … </currencySymbols>
      <typefaces> … </typefaces>
    </locale>
    <locale> … </locale>
</localeSet>

I was able to extract the number symbols with this function:

function findLocaleNumberSymbols(vRefField) {
    var oSymbols = {decimal: ".",
                    minus: "-"
                   };
    var vLocale = localeSet[vRefField.locale];
    if (typeof(vLocale) !== "undefined") {
        var vNumberSymbols = vLocale["#numberSymbols"].nodes;

        for (var i = 0; i < vNumberSymbols.length; i++) {
            oSymbols[vNumberSymbols.item(i).name] =
                                     vNumberSymbols.item(i).value;
        }
    }
    return oSymbols;
}

Using the numeric symbols the form is able to more accurately restrict input for numeric fields.

Choice List Fields

The last field in the sample is a reference to a choice list with the American states.  Try out the editing experience here.  It’s pretty cool:

  • Input characters are limited to the set of valid choices
  • As soon as you type enough characters to uniquely identify a state, the rest of the input is completed automatically

Use Formatted and Edit Values

In the updated sample. the editing field now behaves like any other widget.  When you tab in, referenced field values display in their edit format.  When you tab out, the referenced fields display their formatted value.  In the sample you will notice that the currency and date values change when you tab in/out.  This is functionality that happens automatically on normal fields but had to be emulated in script for this sample.

You don’t have to read through all the script to figure out how it works, but it is worth noting that you can access a field value in three different ways:

  • field.rawValue — the canonical value as it is stored in the data
  • field.formattedValue — the value with the display pattern applied
  • field.editValue — the value with the edit pattern applied

Note that if a format or edit picture/mask is not supplied, there are default patterns for numeric and date values.

Hook up via the enter event

Previously, the editor field tapped into the script object by delegating its initialize, change and exit events.  it now also needs to delegate the enter event:

form1.LetterEdit::change – (JavaScript, client)
scEditFF.handleChangeEvent();

form1.LetterEdit::enter – (JavaScript, client)
scEditFF.handleEnter();

form1.LetterEdit::exit – (JavaScript, client)
scEditFF.handleExit();

form1.LetterEdit::initialize – (JavaScript, client)
scEditFF.initialize(this, Letter, "#c0c0c0", 10);

Futures

There are more constraints that could be enforced, e.g. digits before/after decimal but those

8 Responses to Editable Floating Fields V2

  1. radzmar says:

    Hello,this is really a great work you did.The editor script looks like several sleepless nights, very huge.But I don’t get the form work anymore.I currently can change all the values (e.g. Person1) but when I exit the textfield, all floating fields return to their default.The form worked for a while in my LCD and Acrobat, but suddenly it doesn’t.I was doing some trial and error, because this looks so interesting and damned useful.I destroyed the form (I think), while trying to make the fillable areas with bold fonts and a colored background.Hmm, back to start.So I reopend your basic form again, but since then even this doesn’t update the floating fields with my input.I killed all my LCD/Acrobat-relevant processes on my machine and did a reboot, but no luck.;-/ Any ideas about this behavior?

  2. Radzmar:I suggest re-downloading the sample and making sure it still works (I can’t imagine why it wouldn’t?)My guess is that on your form maybe you missed connecting one of the events on the edit field. Make sure you fill in the enter, exit, change and initialize events.Do any messages showing up in your console window?good luck.John

  3. Radzmar says:

    Hi John,the console shows no exceptions, everything seems to be ok, but still no luck.I’m now tested the scEditFF fragment within a complete new form on another PC but still the same result.If I exit the textfield, the changed value returns to it’s default.I don’t see, what I’m missing.If possible, have a look to my form.https://share.acrobat.com/adc/document.do?docid=927f853f-2f9f-4772-80b6-84d0b445609cThanks in advanceradzmar

  4. radzmar:I see what’s going on now. When the floating field is bolded, it creates xhtml with nested span elements. The xhtml handling in the script doesn’t deal with the nested spans. If you remove the bolding, the form works fine.When I get a chance I’ll issue a fix.John

  5. radzmar:I’ve made a fix. The sample and fragment have been updated.For other interested observers: note that the sample has a “check version” button. If you now click that button on a previously downloaded version of the sample form, you’ll be notified that the embedded fragment has been updated.John

  6. Theodoros Giannakis says:

    Hi John,
    There is any way to avoid the gray background colour behind the floating fields
    when we have to print the form?

    Thank you

  7. radzmar says:

    @Theodoros

    The background color can be changed in the initialize:Event of “LetterEdit”.
    Change
    scEditFF.initialize(this, Letter, “#c0c0c0”, 10);
    into
    scEditFF.initialize(this, Letter, “#ffffff”, 10);
    to get a white background for example.

    • The form has a pre-print event that hides the editable field and makes the draw element visible. So the print version should already be free of the shading.