PaperForms (2D) Barcodes with Repeating Subforms

One of our support engineers brought an issue with 2D barcodes to my attention this week.  I was able to help her with a solution, so I thought I’d share it here as well.

These barcodes encode form field data the user has typed in.  When the form is printed (or perhaps faxed) the barcode can be scanned and the form data retrieved.  This workflow was originally envisioned on static forms with fixed amounts of data — after all, a 2D barcode holds a limited amount of data.  As a result, the design process does not allow the inclusion of repeating subforms in the barcode data.  However, there certainly are cases where we could safely allow some repeating data in a barcode without overflowing the storage capacity.

I’ll show you how to fix the problem first, and then if I still have your attention I’ll give you the details on how it works.

The Fix

When you add your PaperForm barcode to your form, you also define a collection of fields and subforms to include in the barcode value.  If you add any repeating subforms to this list, then at runtime only the first subform instance will be included in the barcode.  In order to have the barcode include more instances, we need to modify the collection.  In the sample form, I’ve done this with an initialization script on the barcode field.  When you re-use this script, you need to change the last line so that it points to your collection:

makeManifestRepeat(BC_Collection);

You need to replace "BC_Collection" with the name of the collection used by your barcode.   There is one other detail needed to make this work for Reader 8.  When you add a new instance of a subform, you need to explicitly fire the barcode calculation.  The sample does this in the button click event:

PaperFormsBarcode1.execCalculate();

How it Works

The UI terminology for the fields included in a barcode is "Collection".  But the grammar calls it a manifest.  The manifest in the sample looks like this:

<manifest name="BC_Collection" id="2ae4d4a5-5e5d-4dba-b50e-e069b91533ce">
  <ref>xfa[0].form[0].bcTest[0].p1[0].Subform1[0].TextField1[0].dataNode</ref>
  <ref>xfa[0].form[0].bcTest[0].p1[0].Subform1[0].TextField2[0].dataNode</ref>
  <ref>xfa[0].form[0].bcTest[0].p1[0].Subform1[0].TextField3[0].dataNode</ref>
</manifest>

The manifest is a list of SOM expressions to the values to be included in the barcode.  Note that our repeating subform explicitly references the first instance: "Subform1[0]".  To make this manifest include all instances, we need to change it to "Subform1[*]":

<manifest name="BC_Collection" id="2ae4d4a5-5e5d-4dba-b50e-e069b91533ce">
  <ref>xfa[0].form[0].bcTest[0].p1[0].Subform1[*].TextField1[0].dataNode</ref>
  <ref>xfa[0].form[0].bcTest[0].p1[0].Subform1[*].TextField2[0].dataNode</ref>
  <ref>xfa[0].form[0].bcTest[0].p1[0].Subform1[*].TextField3[0].dataNode</ref>
</manifest>

 

We could have fixed this by editing the XML source in Designer, but that would be awkward.  Instead, we update the manifest when the form is opened in Reader — that’s the function of the initialization script.