Ever since the release of Acrobat 8.0 last November and, more recently, the Acrobat 7.0.9 update (for those still using Acrobat 7.x), I’ve had a few inquires about forms using ADBC (Acrobat DataBase Connectivity) that suddenly stop working.

The source of the problem is likely the fact that Acrobat 7.0.9 and 8.0 now disable ADBC by default, regardless of whether you were using it prior to the update or not. The reason behind this change is that ADBC poses a sizeable security risk as it doesn’t provide any mechanism to protect the databases it accesses from malicious use.

Although I wish the installation programs for Acrobat 7.0.9 and 8.0 would’ve warned users that ADBC was being disabled and provided them with information on re-enabling it rather than silently disabling it and causing people a lot of grief, I think disabling ADBC when it isn’t needed is much safer than leaving it enabled in case you ever need it.

Alternatively, you may choose to migrate to ODBC data connections in XFA forms (which you can save as PDF files for use in Acrobat). Since these are still enabled in Acrobat 7.0.9/8.0 and also make use of DSNs to locate and access databases, the migration should be relatively seamless to the people using your forms. Please note, however, that exposing a database to any type of audience always creates a certain security risk which should be assessed and addressed accordingly. You might consider creating a web service to act as the bridge between the database and your form (where your form retrieves data from and pushes data into a database via methods provided by a web service), thereby restricting access to your database’s structure and data.

For those needing to (re-)enable ADBC, the Acrobat 8 SDK Readme contains information on how to do that. For your convenience, here is the excerpt which contains the instructions (as they were stated on December 13, 2006):

ADBC Support

Acrobat Database Connectivity (ADBC) can now be turned on and off via a registry setting. To activate ADBC, create a registry key of type DWORD with the name “bJSEnable” and a value of “true” (1) in the following location:

HKEY_CURRENT_USER\SOFTWARE\Adobe\Adobe Acrobat\8.0\ADBC

This activates ADBC in Acrobat 8.0. In previous releases of Acrobat, ADBC was active by default. In Acrobat 8.0, this setting has been changed to require user intervention to activate ADBC because most users do not want to have ADBC accessible from PDF.

Windows shell command to activate ADBC:

reg add “HKEY_CURRENT_USER\SOFTWARE\Adobe\Adobe Acrobat\8.0\ADBC” /v bJSEnable /t REG_DWORD /d 1

For Acrobat 7.0.9 users, simply change all instances of "8.0" to "7.0" in the above instructions.

Please note that since ADBC poses a security risk (as outlined earlier), Adobe does not recommend modifying the registry to re-enable this feature. Also note that ADBC is still only available via Acrobat Standard or Professional and on Windows only. The Adobe Reader does not have the ability to use ADBC.

---

Posted by Stefan Cameron on March 7th, 2007
Filed under Acrobat,Scripting

---

Did you know that periods (.) are valid characters in XFA object names? On the surface, this may seem innocent but it’s really kind of strange when you think about it — especially when it comes to writing scripts: How would you access the properties or methods of an object if had a period in its name?

Consider a simple form with a button and a text field which is named "TheText.Field". Notice the period in the text field’s name. If you wanted to write a little line of script in the button’s Click event which set the text field’s value to some arbitrary text, you would not be able to write the following:

TheText.Field = "text" // FormCalc

It would produce an error because the script engine would think that you’re referencing an object named "Field" which is a child of a parent object named "TheText" when you’re actually trying to reference the "TheText.Field" object.

If XFA allows for periods in object names, there must be a way to access them correctly. To find the answer, one of the things you can do is a little test which exposes the text field’s SOM expression (say, in the text field’s Enter event):

xfa.host.messageBox($.somExpression) // FormCalc

Doing this for the text field would give the following result:

xfa[0].form[0].form1[0].#subform[0].TheText\.Field[0]

Notice the backslash which precedes the period in the "TheText.Field" name: Backslashes are used to escape period characters in XFA names in SOM expressions.

Knowing this important detail, you could change the earlier script to the following:

$.parent.resolveNode("TheText\.Field") = "text" // FormCalc

and everything would work just fine. The resolveNode method is necessary in this case since the script engine doesn’t support backslashes in statements in FormCalc (and neither in JavaScript for that matter).

Finally, don’t forget that backslashes in strings in JavaScript are used to escape other characters such as "\n" for a new line character. This means that when you write the object’s name in the resolveNode method call, be sure to escape the backslash itself in order to give the correct expression to the resolveNode method:

this.parent.resolveNode("TheText\\.Field").rawValue = "text"; // JavaScript

---

Posted by Stefan Cameron on February 14th, 2007
Filed under Scripting

---

Some of you may recall my tutorial on sorting lists at runtime which I posted last June. Oh how I wish I had waited until the release of Designer and Acrobat 8.0 in order to write it! With the new release of these two products comes a new API for list objects that would’ve significantly simplified things: Rather than having to know details about how list object items are represented in XFA (using an <items> node for item text values and an <items save="1"> node for item data values) and manipulating these nodes in script, I could’ve used methods such as getDisplayItem and getSaveItem.

New Properties

• length: Returns the number of items in the list object. This property is read-only.
• selectedIndex: Returns the zero-based index of the first-found item which is selected or -1 if the list has no selection. You may set this property in order to set a new selection in the list or set it to -1 in order to remove the selection entirely. Note that setting this property will first de-select any currently-selected items prior to applying the new selection.

New Methods

• bool getItemState(int index): Returns true (1 in FormCalc) if the list item specified by the zero-based index parameter is currently selected in the list.
• setItemState(int index, bool state): Add or remove a list item from the selection by specifying its zero-based index and true to select or false to de-select it (1 or 0, respectively, in FormCalc). Note that if the list object does not support multiple selection (drop down lists typically don’t), using this method will have the same effect as setting the selectedIndex property.
• string getDisplayItem(int index): Returns a list item’s text value (this pertains to the list’s <items> element in XFA) based on a zero-based index into the list.
• string getSaveItem(int index): Returns a list item’s data value (this pertains to the list’s <items save="1"> element in XFA) based on a zero-based index into the list.
• bool deleteItem(int index): Deletes the list item specified by a zero-based index and returns true (1 in FormCalc) to indicate that the item was effectively deleted.

Demo Form

In order to show-off this cool new API (available in both JavaScript and FormCalc), I designed a little form that uses all the new properties and methods. Play with it in Acrobat 8.0 and check out the script in Designer 8.0. I’m certain it’ll make your life a whole lot easier when it comes to scripting list boxes and drop down lists.

Download Sample [pdf]

Minimum Requirements: Designer 8.0, Acrobat 8.0.

Note that you must click away from the "List Box" object after you’ve set a selection since the list is set to commit its selection on exit (as is recommended when supporting multiple selection). You can specify this by setting the "Commit On" property on the Object palette’s Field tab to "Exit".

---

Posted by Stefan Cameron on February 1st, 2007
Filed under Scripting,Tutorials

---

If you’ve ever written scripts in Designer, you will have noticed that the default scripting language is FormCalc which is a problem if you need to (or prefer) to write your scripts in JavaScript.

The easiest way to make sure that all your new scripts default to the JavaScript language is to use the Form Properties dialog and set JavaScript as the default scripting language (in the Defaults tab). The problem with this setting is that it affects only the current form. If you’re like me, you create lots of forms every day, you constantly forget that the default scripting language is FormCalc and you only remember once you’re running your form and you get a FormCalc error message box in Acrobat telling you that your syntax is incorrect. How annoying!

Fortunately, there’s a way to set JavaScript as the default scripting language for all new forms — based on a specific template. The default setting for the scripting language is actually specified as a processing instruction in the XML Source. If you create a new document and go to the XML Source tab, you’ll find the following processing instruction set as a child of the <template> element (also shown in the image below):

<?templateDesigner DefaultLanguage FormCalc?>

Since all new documents created in Designer are based on templates and that each template comes with its own set of processing instructions, modifying the processing instruction in the template would effectively modify the default scripting language on all new forms based on that template. Going one step further and making that modified template your default template would ensure makes things even easier when you’re creating new forms.

Fortunately, you don’t have go to the XML Source view to modify this processing instruction. Instead, you can set its value using the Form Properties dialog (accessible via the File menu): In the Defaults tab, set the Default Language property to “JavaScript”.

Modifying Designer Templates

In Designer, you use the Template Manager to organize your templates. You can access the Template Manager from the Tools menu.

To modify a template, you can follow these easy steps:

1. Create a new document based on the template you wish to modify.
2. Make the necessary modifications (like setting the processing instruction for the default scripting language setting to "JavaScript").
3. Save the new document as an "Adobe LiveCycle Designer Template (*.tds)" file. If you want to replace an existing template (say "Letter"), use that same name as the file name for the new (modified) template file you’re saving.
4. Using the Template Manager, select the tab pertaining to the group in which you want to add your new template. If you’re wanting to replace the "Letter" template, for example, select the "Standard" tab.
5. Right-click in the list panel and select "Add Template…". Select the template you just saved and it’ll be added to Designer’s "template store". Note that if the name of your new template file is the same as an existing template in the group you selected (e.g. the "Letter" template in the "Standard" group), you’ll be prompted to overwrite the existing template.

One important thing to note in the way Designer handles templates is that any template file you add to the Template Manager gets copied into the "template store" which means that new documents based on that template aren’t actually based on the template file in the location where you saved it but rather on the copy that was placed in the "template store".

If you’re wondering what the "template store" is, it’s actually a folder inside Designer’s Application Data folder on your system. While I don’t encourage you to look in there (because you might see things that look interesting but you shouldn’t be playing with ;), if you find them, then you should also be able to open them directly in Designer and modify them without having to create a separate copy.

_{Updated: January 17, 2006}

---

Posted by Stefan Cameron on January 10th, 2007
Filed under Events,Script Editor,Scripting

---

I was looking around in the LiveCycle Developer Center today and came across a great beginner’s guide to scripting in Designer that Alex Mitchell, a colleague of mine here at Adobe, recently posted to the site.

Even though it’s labelled as "beginner", there’s some great stuff in there regardless of your level of expertise. For example, there are some really nice flow charts illustrating the order of execution of form and field events and the section on Creating and Resuing JavaScript Functions should come-in handy for those complex forms. There are also some examples of common scripting tasks which could be useful in all types of forms.

---

Posted by Stefan Cameron on January 4th, 2007
Filed under Scripting

---