Archive for July, 2006

Dynamic Properties

Posted on July 29, 2006 by Stefan Cameron | Comments (4)

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]“:http://blogs.adobe.com/formbuilder/samples/DataBinding/DynamicProperties.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.

Continue reading…

Seeing the Entire Value

Posted on July 26, 2006 by Stefan Cameron | Comments (14)

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):

bc. $.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).

== ==

Previewing as Dynamic PDF

Posted on July 24, 2006 by Stefan Cameron | Comments (3)

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”:http://blogs.adobe.com/formbuilder/scripting/instance_manager 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:

# 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.
# 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):

# 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.
# If you’ve saved your form as a _dynamic_ PDF, make sure the _Preview Type_ is set to “Interactive”.
# 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.
# 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.
# 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~

Form Variable Tip

Posted on July 16, 2006 by Stefan Cameron | Comments (23)

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

bc. MyVar = “test”

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

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

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

bc.
test

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:

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

bc. MyField

as opposed to having to write

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

Adobe MAX 2006

Posted on July 10, 2006 by Stefan Cameron | Comments (0)

Adobe has “just released”:http://www.adobe.com/aboutadobe/pressroom/pressreleases/200607/071006MAX.html details about “Adobe MAX 2006″:http://www.adobemax06.com, along with “schedules and track information”:http://www.adobe.com/events/max/agenda.

Where does “Designer”:http://www.adobe.com/products/server/adobedesigner fit in all this? You’ll find a whole track on Adobe’s “LiveCycle products”:http://www.adobe.com/products/livecycle, including a hands-on session on Designer, on the “LiveCycle Track Agenda”:http://www.adobe.com/events/max/agenda/by_track.html#livecycle.

Make sure you “register”:http://www.adobemax06.com early. This is an event not to be missed!

Demystifying IM.AddInstance

Posted on July 8, 2006 by Stefan Cameron | Comments (7)

The definition for the Instance Manager’s addInstance method is as follows:

bc. addInstance( [BOOLEAN param] )

Personally, I find the word _param_ a little vague. I think it should be called _merge_ instead because that would give a clearer indication as to what it stands for: Essentially, if the data you’ve merged into your form has a repeating section that you’ve bound to a repeating (dynamic) subform and not all instances of this repeating data section have been merged into the form’s layout, you can control whether the new instance of the dynamic subform pertaining to that repeating data section will get merged with the next section or not by specifying _true_ (merge — the default) or _false_ (don’t merge — show empty instance) as the parameter value.

Usually, this doesn’t make a difference because you typically merge all instances of a repeating data section into your form and once there are no more data instances to merge, addInstance(true) will yield the same results as addInstance(false): an new empty (no data merged-in) instance.

Consider, however, the case where your form is a report and you’d like to show only a glimpse of the data instead of loading all 2000 instances of a repeating section. If your data was sorted from the most important to the least important, you could significantly *improve the performance* of your report (with respect to load time) by limiting the number of instances of that repeating data section that are initially merged into your form. Once your form is loaded, it could provide ways for the reader to get more instances if they wish to do so.

This can be achieved by using the Max property on the dynamic subform’s Binding tab in the Object palette along with addInstance([*true*]).

Here’s a sample which has a data connection to an XML Data File that lists movies. There are 16 movies in total but the form limits the number of movies initially displayed to 10 and provides a _Show More_ button. When this button is pressed, the movie dynamic subform’s Max count property, initially set to 10, is incremented by 1 and a new movie instance is added using _true_ as the parameter.

“Download Sample [zip]“:http://blogs.adobe.com/formbuilder/samples/im/AddInstanceTrueFalse.zip

*Minimum Requirements:* Designer 7.0, Acrobat 7.0.

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