Did you know that as of Designer 7.1, there’s way to automatically populate certain field properties with data without having to write any script? This is what the new Dynamic Properties feature is designed to do.

First, you have to enable it because it’s disabled by default. You can do this by going to the Data Binding panel in the “Tools | Options” dialog. There, you’ll find a check box labeled, “Show Dynamic Properties”. Check the box and press OK. After doing so, put a list box (for example) on the form and take note of the changes in the Object palette’s Field, Value and Binding tabs.

You’ll notice that some property labels have now changed color (default is green) and are underlined. You can now click these property labels to make the properties they pertain to dynamic (i.e. to automatically push values into them when data is loaded into the form via a certain data connection that you specify). For instance, the Field tab now has dynamic Caption and List Items properties.

If you click on the List Items label, you’ll get the following dialog (this screen shot shows the properties already configured for this sample):

Using the Dynamic Property dialog (above), you can then specify the data connection from which the data will be loaded and also the data node(s) that will contain the data (in this case, for a list field, you can bind data nodes to the text and value items of the list).

Download Sample [zip]

Minimum Requirements: Designer 7.1, Acrobat Pro 7.0.5

Note: If you open the form in Acrobat, don’t forget to import the data into it using the “File | Form Data” menu.

For this sample, we’re trying to list all the movie titles and, when a movie is picked from the list, display its show time in a date/time field on the form. Therefore, we’ve bound all movie data

$record.movie[*]

to the list and then we’ve bound the text items to the

title

data node (which translates to “$record.movie[*].title” since it’s relative to the property’s binding) and the value items to the

showTime

data node (which translates to “$record.movie[*].showTime”).

Based on these settings for the list’s text and value items, the list will be automatically populated with all movie titles and show times when the movie data is imported into the form. All this without having to write a single line of script!

By the way, if you’re curious about the script you would have to write in order to do the equivalent without using the Dynamic Properties feature, just drop a “Data List Box” or “Data Drop Down List” object, from the Library palette’s Custom tab, onto the form and have a look at the script in its Initialize event. Now that’s not simple script! Of course, there are advantages to using script over Dynamic Properties because script is more flexible but in this case, there’s really no need to worry about using script.

Once you’ve filled-in the properties inside the Dynamic Properties dialog for the list box’s List Items property, you’ll notice that the property’s label now has a little “link” icon to signify that the property is bound to nodes in a data connection:

Finally, you just need a single line of script in the list box’s Change event to display a selected movie’s show time in a field on the form (in FormCalc):

ShowTime = $.boundItem(xfa.event.newText)

Please note that the Dynamic Properties feature is still in its early stages therefore it only handles simple data binding situations like the one for this sample. Many customers who’ve discovered this feature attempt to use it in dynamic subforms in order to populate lists with data pertaining to the current record and soon discover that the lists always end-up containing identical record data when they use the Dynamic Properties feature. That’s because the feature simply doesn’t yet support dynamically updating the data node occurrence which is used to populate a list, for example (that is, updating the occurrence of the “$record.movie” binding to a specific occurrence as opposed to always using [*]).

---

Posted by Stefan Cameron on July 29th, 2006
Filed under Data Binding,Tutorials

---

I’m sure many of you out there have run into problems with fields on printed forms where the value entered in the field was too long to fit within the field’s visible area. The result is a black “+” sign on the lower left corner of the field — not much help in reading the entire content when it’s printed and you can’t scroll anymore:

What if there was a way to configure the field so that the entered value’s font size would automatically shrink to fit the value within the field’s visible area (down to a certain limit)? Of course, it’s possible the text may end-up too small to read without a magnifying glass but the entire content would be printed nonetheless (as long as the minimum font size wasn’t hit):

The trick here is to set the field’s value font to a size of zero (0) but it’s not as obvious as it may seem…

In Designer, there are two ways to do this:

The first is to use script in the field’s Initialize event (FormCalc in this case but JavaScript would do just fine too):

$.font.size = "0pt"

The second is to use the Font palette. In this case, however, only the value font’s size may be set to zero. Attempting to set the font size for the caption (or the caption and value combined) to zero won’t work. To specify the value font only, use the Selector widget at the top (highlighted in green on the image below) and pick the Edit Value item. Then, set the font size to zero (highlighted in yellow).

---

Posted by Stefan Cameron on July 26th, 2006
Filed under Designer

---

Have you ever lived through the frustration of previewing a form on which you’ve written a simple little script to affect the presence of an object when a button is clicked and pulling your hair out because you keep clicking on the button and nothing happens (object doesn’t disappear, there’s no error message, etc.)? Or maybe you’ve been in a situation where you’ve added script to a button in order to insert a new instance of a repeatable subform and while clicking on the button doesn’t produce one, the submitted XML data file contains entries for each new instance that was added?

Even if you haven’t, it may happen someday so here’s the remedy for the case of the “Common (Static PDF) Flue”…

In Designer, there are two different locations containing settings which affect the type of temporary PDF file created when you click on the Preview tab:

1. Under the “File Options” section within the “Document Handling” panel of the “Tools | Options” dialog, you can set the Default File Type for New Forms. This type is used on new forms which you preview prior to saving (because Designer doesn’t know which format you’ll use at the time of preview). This is set to a static PDF format by default.
2. Even if you’ve specified a dynamic PDF format for the Default File Type for New Forms, this setting may be overridden by the Preview Type and XDP Preview Format properties in the “File | Form Properties” dialog in the “Defaults” panel once you’ve saved your form. The Preview Type property, set to “Interactive” by default, determines whether the form will be previewed as an interactive (dynamic) form or as a print (static) form. This property supersedes the PDF format. The XDP Preview Format property usually picks-up the Default File Type for New Forms setting and determines what PDF format will be used to preview your form should it be saved as an XDP. (Note that if you’ve saved your form as a PDF file, then the XDP Preview Format setting is ignored).

Now that we’ve covered the different properties which affect the PDF preview format, here’s how to kick that flue I was talking about earlier (so that you actually do preview in a dynamic PDF format and stop pulling your hair out):

1. If you haven’t saved your form, make sure the Preview Type is set to “Interactive” and that the Default File Type for New Forms is set to a dynamic PDF format. You may also want to set the XDP Preview Format to a dynamic PDF format while you’re at it.
2. If you’ve saved your form as a dynamic PDF, make sure the Preview Type is set to “Interactive”.
3. If you’ve saved your form as a static PDF, none of these settings will help you. You must first save your form as a dynamic PDF.
4. If you’ve saved your form as an XDP, make sure the Preview Type is set to “Interactive” and the XDP Preview Format is set to a dynamic PDF format.
5. If you’re tired of running into these problems and want to avoid them in the future, just set your Default File Type for New Forms to a dynamic PDF format.

I hope this tip improves your form design health. It did wonders for me!

_{Updated: January 27, 2007}

---

Posted by Stefan Cameron on July 24th, 2006
Filed under Debugging,Designer,Scripting

---

Form Variables can be useful because you can store string values into them that are persisted across object events as opposed to variables created locally (within scripted events) which are destroyed at the end of every event.

You can create Form Variables by going to the Variables tab within the Form Properties dialog, accessed via the main File menu.

The catch is in the way you get and set their values: If you’re writing a FormCalc script, then you can manipulate them just like any other variable. For example, let’s say you define one named “MyVar”. In your script, you can then write

MyVar = "test"

to assign the value “test” to it and you can write

xfa.host.messageBox(MyVar)

to display its value in a message box.

If you were then to change the script’s language to JavaScript and attempted to display the variable’s value in a message box as above, you would get the following error:

GeneralError: Operation failed.
XFAObject.messageBox:1:XFA:form1[0].#subform[0].Button1[0]:click
Argument mismatch in property or function argument

This is because FormCalc helps you by doing things “under the hood” based on the context in order to get and set the value of a Form Variable whereas JavaScript doesn’t.

If you look at the XFA definition of the variable, it looks like this:

<variables>
  <text name="MyVar">test</text>
</variables>

This means that the value of the “MyVar” Form Variable is actually contained within the MyVar element’s content which must be accessed via the value property. Therefore, in order to access a Form Variable’s value in JavaScript, you need to do this:

MyVar.value = "test"; // set the value
xfa.host.messageBox(MyVar.value); // get the value

Just like being able to simply write a field’s name like this in a FormCalc script in order to access its value

MyField

as opposed to having to write

MyField.rawValue

in JavaScript, you need to specify the property you’re accessing on the object in JavaScript when accessing the value of a Form Variable (which is always the value property).

---

Posted by Stefan Cameron on July 16th, 2006
Filed under Scripting

---

Adobe has just released details about Adobe MAX 2006, along with schedules and track information.

Where does Designer fit in all this? You’ll find a whole track on Adobe’s LiveCycle products, including a hands-on session on Designer, on the LiveCycle Track Agenda.

Make sure you register early. This is an event not to be missed!

---

Posted by Stefan Cameron on July 10th, 2006
Filed under Conferences,MAX 2006

---