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”:http://blogs.adobe.com/formbuilder/2006/06/invalid_flashing_fields.html 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”:http://blogs.adobe.com/formbuilder/2006/06/acroform_objects.html Scripting Object Model.

The _app.setInterval_ script therefore changes from this:

bc. 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:

bc. 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”:http://blogs.adobe.com/formbuilder/2006/06/acroform_objects.html 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.

“Download Sample [pdf]”:http://blogs.adobe.com/formbuilder/samples/AcroFormObjects/InvalidFlashingFields-WithoutAFGetField.pdf

*Minimum Requirements:* Designer 7.1, Acrobat 7.0.5.

2 Responses to Invalid Flashing Fields 2.0

  1. Michael Ramirez says:

    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?

  2. 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.