FormBuilder

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.

I just recently received another “comment from Zack”:http://blogs.adobe.com/formbuilder/2006/08/autolocalizing_your_forms.html#comment-18302. This time, he was wondering about how one would go about tracking mouse clicks on an image field.

I had never attempted to do that so I took it on as a challenge and thought I would share the results in this post.

I knew from the start that XFA alone wasn’t going to be able to handle this simply because (to my knowledge) it doesn’t provide any information as to the position of the mouse pointer when an event occurs. The most logical place I thought would’ve provided the information — the _Event Pseudo Model_ (the xfa.event object available in all XFA events) — didn’t live up to my expectations. Thankfully, XFA at least provides a Click event so that I could know when the image got clicked.

The next logical place to look was in Acrobat’s Scripting Object Model (in the “AcroForm Objects”:http://blogs.adobe.com/formbuilder/2006/06/acroform_objects.html). In the Acrobat Document object, I found what I was looking for: the _mouseX_ and _mouseY_ properties which provided the location of the mouse with respect to the document window.

The last thing I needed was information about the dimensions and location (within the Acrobat Document Object’s coordinate space) of the image field and the Acrobat Field object’s _rect_ property would give me just that.

The combination of the XFA Click event, the Acrobat Document object’s mouseX and mouseY properties and the Field object’s rect property was just what I needed to get this to work.

Of course, I soon discovered that I had another problem to figure-out: The behaviour of an image field in a PDF form running in Acrobat is that when clicked, it opens a browse dialog that lets you pick the content for the field. Unfortunately, there isn’t any way to suppress that dialog other than making the image field read-only or by using a static image object but then both alternatives prevent the Click event from firing. So I needed some clever way to capture a mouse click over an image (whether it was a field or a static object) and I decided to use a button with a transparent fill and no border (so it was essentially transparent). Since buttons are fields just like image fields, the mouseX, mouseY and rect properties would still be available for the button and if I sized the button to fit the image and placed it over-top, I would essentially end-up with an HTML <map>.

“Download Sample [pdf]“:http://blogs.adobe.com/formbuilder/samples/AcroFormObjects/TrackingMouseClicks.pdf

*Minimum Requirements:* Designer 7.1, Acrobat 7.0.5.

Continue reading…