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.
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:
GeneralError: Operation failed. XFAObject.someField:2935:XFA:form1:bodyPage:subformObj:otherField:initialize Invalid property get operation; subform doesn't have property 'someField'
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.
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:
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,
Posted by Stefan Cameron on February 11th, 2009
Filed under Acrobat,Debugging,Designer,Scripting,XFA
Both comments and pings are currently closed.