Invalid Flashing Fields 2.0
A colleague of mine here at Adobe pointed-out today that the use of the AcroForm Document object’s getField method wasn’t necessary in the script I used for my original Invalid Flashing Fields sample.
There’s an alternative which uses xfa.form.resolveNode in the app.setInterval script. xfa.form.resolveNode takes a SOM Expression and returns a reference to an XFA node. What’s more is that this API call can be made from within the context of the AcroForm Scripting Object Model.
The app.setInterval script therefore changes from this:
moFlashTimerID = app.setInterval(
"var f = this.getField('" +
GetAcroFormFieldName(oField) + "'); " +
"if (color.equal(f.fillColor, color.red))" +
"{ f.fillColor = [" + moAcroFieldFillColor.toString() + "]; }" +
"else" +
"{ f.fillColor = color.red; }",
500);to this:
moFlashTimerID = app.setInterval(
"var f = xfa.form.resolveNode('" +
oField.somExpression + "'); " +
"if (f.ui.oneOfChild.border.fill.color.value == '255,0,0')" +
"{ f.ui.oneOfChild.border.fill.color.value = '232,232,232'; }" +
"else" +
"{ f.ui.oneOfChild.border.fill.color.value = '255,0,0'; }",
500);Also note the changes in the way the color values are compared and assigned (whereby the newer version uses more familiar XFA script rather than the AcroForm script from the first version).
Since the use of the AcroForm Scripting Object Model should always be secondary to using the XFA Scripting Object Model (because AcroForm objects are, after all, in a separate Object Model which may change separately from the XFA Scripting Object Model), I wanted to highlight this alternative which makes more extensive use of the XFA Scripting Object Model than the first version did.
Minimum Requirements: Designer 7.1, Acrobat 7.0.5.
August 22nd, 2006 at 3:13 pm
How would you apply complex validation rules to a pdf docuemnt. For example, field A cannot be blank if fields B & C are filled or field E is checked. Can you reuse validation libraries across different forms?
August 24th, 2006 at 3:06 pm
Michael,
Your question prompted a new post on my blog with a sample on how to do complex validations prior to submitting a form. See Complex Validations.
As for reusing script across different forms, that’s possible by using a combination of script objects, subforms and the Library palette: Place a subform on the form and, in the Hierarchy palette, right-click on the subform you just inserted and select Insert Script Object. Then, select the script object and give it a name and use the Script Editor to write script (note that only JavaScript may be used in script objects). Once you’re finished, make the subform invisible using the Object palette’s Subform tab and drag the subform to the Library palette. That’ll create a new object in the Library that you can drag and drop onto any form. Say you named the subform “Subform1″ and the script object “ScriptObject”, you would when access the script by writing a JavaScript (on a button’s Click event, for example) with a statement like “Subform1.ScriptObject.MyFunction();”
The problem with that approach is that if you need to modify the scripts in the script object, you’ll have to go back and fix all the forms that use it because dragging and dropping from the Library onto a form create a copy of that object — not a reference.
Since I’m quite certain you’re looking for a reference rather than a copy, I’ll have to ask you to be a little patient because it’s possible we may address that issue in a future release.