Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

Careful with Form Compatibility Settings

Let me put it simply: I got burned by using a particular syntax to check the existence of a field inside a subform object due to form compatibility settings in LiveCycle Designer 8.2.

What?

It started with a form I had created using Designer 8.1 which was set to target Acrobat 8.1/XFA 2.6. Later-on, I installed Designer 8.2 and wanted to update my form to target Acrobat 9/XFA 2.8.

In my form, I had a script object with various functions that used the following syntax to test the existence of a field inside a subform object which was passed-in to these functions as a parameter:

if (subformObj.someField)

The result of this was what I expected: If ‘someField’ existed inside ‘subformObj’, the IF statement would evaluate to ‘true’; if it didn’t, it would evaluate to ‘false’. According to the rules of dynamic properties in JavaScript, this was all fine and dandy.

All my scripts were set to run on client only. Then I found myself having to execute them on the server. So I set all my scripts, including my script object, to Run At ‘Client and Server’ using the Script Editor. That’s when the problems first started showing-up. The server log showed the following error messages whenever the JavaScript engine would come across the above IF statements in cases where, after a little investigating, I determined ‘someField’ was not inside ‘subformObj’:

GeneralError: Operation failed.
XFAObject.someField:2935:XFA:form1[0]:bodyPage[0]:subformObj[0]:otherField[0]:initialize
Invalid property get operation; subform doesn't have property 'someField'

But why was I getting these error messages? My form was executing just fine in those circumstances on the client (in Acrobat and Reader 9) and I even had "Form Properties > Defaults > Enforce Strict Scoping Rules in JavaScript" enabled in my form.

Why?

Well it turns-out that while my form was now targetting Acrobat 9/XFA 2.8 (since my <template> node’s namespace, in the XML Source view, was properly set to "http://www.xfa.org/schema/xfa-template/2.8/"), it was still behaving like an XFA 2.6 form! That meant that my scripts were subject to the same rules as scripts running in Acrobat 8.1, not Acrobat 9.

Back in Acrobat 8.1/XFA 2.6, the client-side XFAObject form objects in JavaScript supported the addition of custom/dynamic properties yet the server-side (LiveCycle; xfa.host.name == "XFAPresentationAgent") ones did not. Hence the error messages like the one above.

How did this happen? Well, when I opened my old Designer 8.1 form in Designer 8.2 and updated its target to Acrobat/Reader 9 and XFA 2.8, Designer did what it does by default which is insert the following processing instruction in the form in order to give the form access to the new XFA 2.8 APIs yet make it still behave like an XFA 2.6 form in order to maintain compatibility:

<?originalXFAVersion http://www.xfa.org/schema/xfa-template/2.6/?>

Unfortunately, that’s not what I wanted. My intention, when updating the form’s target version, was to make that form Acrobat 9 + XFA 2.8 compliant — even if it meant I had to potentially deal with some behavioral differences — in order to take full advantage of all the new features and bug fixes.

Once I removed the offending processing instruction (by going to the XML Source view in Designer and removing it manually since there’s no UI to do this), Acrobat and Reader 9 began to throw the same exceptions as the server which was good because it meant I was finally in the situation I had wanted all along: XFA 2.8 compatibility and behavior!

Thankfully, fixing my script wasn’t too difficult. The new version,

if (subformObj.resolveNode("someField"))

works very predictably for both client- and server-side rendering and what’s more, the custom/dynamic properties I do create on regular JavaScript Object variables are safe from garbage collection.

Recommendations

If you want to understand more about form target and compatibility settings along with the do’s and don’ts of custom properties in JavaScript within XFA forms, I highly recommend you read John Brinkman’s posts on the scope of JavaScript objects and form compatibility settings.


Posted by Stefan Cameron on February 11th, 2009
Filed under Acrobat,Debugging,Designer,Scripting,XFA
Both comments and pings are currently closed.

One Response to “Careful with Form Compatibility Settings”

  1. Justin on May 6th, 2010

    Hi Stefan,
    Since the inception of a livecycle form into production, I’ve continually had an issue with the interaction of the livecycle form with our web service. The web service call appears to be working properly around 75-80% of the time but randomly fails to be executed. I have stress tested the web service and have not been able to replicate the error we’re experiencing in production. Recently we’ve put some low level debugging on the form to try and determine exactly what could be causing this issue however we don’t seem to be having a lot of luck.

    The error that occurs is very generic. The code that calls the web service is as follows

    try{
    xfa.data.Submission.Common.SignaturesRequired.value =”true”;
    debug.traceLog(“DivisionalOffice.DetermineDivisionalOfficeWSAddress – About to call AECDivisionalOfficeWSProd service.”);
    xfa.connectionSet.AECDivisionalOfficeWSProd.execute(false);
    debug.traceLog(“DivisionalOffice.DetermineDivisionalOfficeWSAddress – Returned from call AECDivisionalOfficeWSProd service without exception.”);
    }
    catch(err){
    debug.errorLog(“DivisionalOffice.DetermineDivisionalOfficeWSAddress – Exception thrown during call to AECDivisionalOfficeWSProd: ” +err);
    webservicecalled =”false”;
    xfa.data.Submission.Common.SignaturesRequired.value =”true”;
    Submission.FlowedPage.Checklist1.returnDivisionalAddress.rawValue =DefaultStateAddress.value;
    Submission.FlowedPage.PrintSubform.Subform21.DivisionalAddress.rawValue =postSubmissionMessage +DefaultStateAddress.value;
    }

    The resulting trace shows the following;
    [trace] DivisionalOffice.DetermineDivisionalOfficeWSAddress – About to call AECDivisionalOfficeWSProd service.
    2010:04:04, 13:05:55:051[error] DivisionalOffice.DetermineDivisionalOfficeWSAddress – Exception thrown during call to AECDivisionalOfficeWSProd: GeneralError: Operation failed.
    ||2010:04:04, 13:05:55:051[trace] StructuredPostCode.exit – Returned from call to DivisionalOffice.DetermineDivisionalOfficeWSAddress

    It looks to me as though the actual execute command is failing immediately. Do you know why this could be happening? It’s something we’ve been looking into for a couple of months but it is impossible to reproduce I’m wondering, coult it be a platform/reader version issue? I have a check to ensure the reader version is at least 8.2.

    Regards

    Justin