Bug in populating PDF with XFA from VBA

[Hieronymus_9]

I've been attempting to populate IRS tax forms with VBA.

--For text-type fields, I can just set Fields(<field name>).Value to the desired string, and the value is correctly stored.

--Checkboxes, however, although they appear to be populated when I view the form in the Acrobat window before closing it, come up blank when the form is next opened in Acrobat or Reader.

--By browsing the internal PDF structure in Preflight, I find that my populating code has correctly set the checkbox value (V), the AP, and the AS values for the checkbox in the Fields object of the AcroForm. However, it has not set the correct values for the checkboxes in the tags in the datasets code of the XFA object, whereas it has done so for the text fields.

--Call to Adobe's service line was of no avail; as soon as the operator heard the letters "XFA", she had all she needed to give me the brushoff: the form was created in LiveCycle Designer, it's not Acrobat's problem, I'll have to purchase Adobe Experience Manager. Which looks to be an enterprise-scale investment.

--I submit that the problem is still an Acrobat problem, because Acrobat, even Reader, knows enough to populate XFA correctly and to rely on it rather than the Fields to decide what to display. The AcroForm VBA plugin also correctly populates XFA for text fields, but fails to do so for checkboxes. Fixing the plugin for the next update will solve the problem completely. I need to get this information past the gatekeepers to the eyes of the Acrobat team.

[Bernd Alheit]

How does you set the checkboxes?

[Hieronymus_9]

Another part of my utility retrieves the field names, types, and values and can then check the values. To find out what values to write, I switch to the Acrobat window, check and uncheck boxes as desired, then switch back to my utility and reread the values. So I found out that, e.g., for the Filing Status boxes on Form 1040, which behave like radio buttons, I have to write the selection value to all the boxes; say, Single means all the boxes get their values set to 1, Married Filing Jointly means they all get set to 2, etc. They are all 0 if no box is checked. Writing 2 to the .Value of all of them does the trick as far as the Fields go: all the boxes' /V are set to /2, box 2's /AS is set to /2 while all the others' are set to /Off. 

[Hieronymus_9]

... and I just found out that this behavior on the part of Acrobat and Reader is also incorrect. When I check one of the Filing Status boxes, it should set the /V of only the checked box to its export value and set the /V of all the other boxes in the group to 0 (or remove the /V's of those). Setting the other boxes to a value that is neither 0 nor their export values causes them to appear X'd when I open the populated form in a competitor's free PDF viewer.

[Test Screen Name]

If you want to get suggestions and bug reports to Adobe the place is https://www.adobe.com/products/wishform.html

It might be that it works by accident, rather than design; you're working with Acroform compatibility layers rather than core XFA. I could mention that Adobe strategic direction with AEM (and hence with XFA forms which belong to the AEM team) is to move completely away from XFA PDF as a deliverable to end users; instead AEM includes modules for a web site to dynamicaly deliver XFA functionality as live HTML forms. This overcomes the increasing difficulty getting users to use an XFA capable reader, and also means there will never be XFA support in the mobile readers. PDF 2.0 has dropped XFA too.

[Hieronymus_9]

Maybe someone will tell the IRS 😉
Thanks for the link!

[Thom Parker]

Have you tried accessing the fields through the XFA scripting model?  Even though the PDF may be a static XFA document, the actual field value are not really stored in the PDF form fields, they are stored in the XFA data model. So the text values are not stored in the form as you think they are. 

[Hieronymus_9]

 I don't have LiveCycle itself, which I gather is necessary to use the XFA scripting model. I see that the actual field values *are* stored in the PDF form fields, and that the operation of setting the PDF Fields(...).Value *also* causes the XFA to be set correctly for text fields, but *not* for checkboxes. The inconsistency is the bug.

I find that when I open the PDF using someone else's free PDF viewer instead of Acrobat or Reader, the checkboxes show up correctly set, because that viewer doesn't mess with XFA at all. This may be the solution to my client's problem.