Archive for May, 2006

Phoenix Was Awesome!

Well, the 37th BFMA Symposium is already over and it seems like it went by way too fast!

I just wanted to thank all the members that came to see us at our Vendor Suite and pulled us asside in the halls to ask questions and give us feedback. Although the sessions I attended were all very interesting and beneficial, the best part was getting to meet you in person and talking about your issues and being challenged to find solutions to your problems (especially with Designer).

Continue reading…

Remove, Remerge

There’s a bug currently logged against Acrobat 7.x where removing an instance of a dynamic subform, using the “Instance Manager”:http://blogs.adobe.com/formbuilder/2006/05/instantiating_subforms_at_runt.html (IM)’s _removeInstance(int)_ method, doesn’t cause an update to the IM’s _count_ of currently instantiated subforms.

OK, so maybe that was a little too technical so I’ll try to simplify: In Acrobat 7.x, when you remove an instance of a dynamic subform using the IM’s _removeInstance(int)_ method and then check the number of remaining instances using the _count_ property, the number you’ll get won’t reflect the number that remains.

Adobe is aware of this bug and will hopefully be providing a fix for it in an up-coming release.

Fortunately, there’s a simple work-around (and even if the bug gets fixed in a future release, you should probably be checking the version of Acrobat that’s running your form to determine whether you need to be using the work-around or not):

bc.. _DynamicSubformInstanceManager.removeInstance(3);

// Force a remerge of the form’s current data set with its template
// to cause an update to the “count” property of all IMs
xfa.form.remerge();

Continue reading…

Add, Recalculate

Here’s a little something that very important to know when working with dynamic subforms and using their “Instance Managers”:http://blogs.adobe.com/formbuilder/2006/05/instantiating_subforms_at_runt.html (IMs) to add instances of them to a form: New subform instances aren’t automatically incorporated into the form’s calculations!

You would immediately notice this problem if you had a form which calculated a total based on line items which can be added or removed from the form. When you add a new line item using the IM’s _addInstance(bool)_ method, the grand total of, say, the cost of all line items isn’t updated to reflect the data you enter into the new line item. This is because the new line item hasn’t been made part of the form’s set of calculation dependencies and is therefore not accounted for by your “grand total” calculation. As a matter of fact, until a call to xfa.form.recalculate() is made, none of the new instances added will be included in the form’s calculations.

To demonstrate this, I’ve created a sample form which has a “line item” section to which line items can be added. As line items are added and their costs changed, the grand total fields at the bottom calculate the total cost of the order: One grand total field performs its calculation using the FormCalc _SUM_ function and a SOM Expression identifying the collection of fields to total while the other uses the LineItem dynamic subform’s IM object to calculate the grand total. Finally, there’s a check box at the top of the repeating “line item” section which, when checked, will cause the “Add Item” button to execute the xfa.form.recalculate(true) statement after adding a new line item. To see the difference, play around with the form by adding line items with the check box both checked and unchecked.

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

*Minimum Requirements:* Designer 7.x, Acrobat 7.x.

BFMA, Phoenix, 2006

I’m very excited to be attending the “BFMA”:http://www.bfma.org’s “37th International Symposium on Forms and Business Processes”:http://www.bfma.org/training/symp06/index.html this coming week in Phoenix, AZ.

Adobe is one of many sponsors for the event. It’s going to be a very exciting time for all of us!

If you have any questions about how to do stuff in Designer as well as some of the things you’d like to see in future releases, don’t be shy! I’m always trying to find new ways to make our product better and I’d love to meet you and get some feedback on what you like and what you don’t like.

Is that Field Empty?

As a form designer, you can be almost certain that there will be a time when you’ll need to check a field to see whether its value is empty (whether the form filler has specified a value).

For longest time, I had been doing it like this in *JavaScript*:

bc. if (theField.rawValue ====== null || theField.rawValue.length ====== 0)
// field is empty
else
// field has been filled

p. That served me quite well until yesterday when I found myself needing to do the same, but this time in *FormCalc*. Theoretically, the following should’ve worked:

bc. if (theField ====== null | theField ====== “”) then
// field is empty
else
// field has been filled
endif

But for some reason, the FormCalc interpreter was giving me a hard time with the _null_ keyword (maybe it’s because I don’t use it very often and it was upset at me, I don’t know — if you’re a developer, you’ll understand that sometimes, code can have feelings and a mind of its own ;) ) so was forced to try and find some other way to check if a field’s value is null in FormCalc and I found one:

bc. theField.isNull

The *isNull* property (of the XFA Scripting Model’s _node_ object) “indicates whether the current *data value* is the null value”, as stated on page 422 of the “Adobe XML Form Object Model Reference”:http://www.adobe.com/devnet/livecycle/designing_forms.html (located in the XML section).

This means that the following *JavaScript* expression checks whether a field’s value is empty:

bc. (theField.isNull || theField.rawValue.length ====== 0)

And in *FormCalc*:

bc. (theField.isNull | theField ====== “”)

Instantiating Subforms at Runtime

Something that’s often desired, when working with dynamic forms, is to let the user specify, at run time (in Acrobat), how many lines of information are required to specify what they want.

The classic example is a Purchase Order form on which there are objects (usually buttons) which let you add and remove item lines from the section of the form which calculates the total cost of the order based on how many items are being ordered and the quantity and cost of each item.

In order to achieve this, the use of the *Instance Manager* is required. The Instance Manager is an object which exists only on _repeatable_ subforms (this could be a subform which is parented to a _flowed_ subform and set to repeat for each data item or it could be a row in a table — since rows and tables are, essentially, subforms). With this special object, you can modify the set of instances of a repeatable (dynamic) subform.

Continue reading…

Calculate Scripts

I just learned something very interesting while answering a forum thread just now which I thought I should share with the rest of you.

In all the scripts I’ve written so far, I had never realized this simple rule: When writing calculation scripts to set the value of certain fields, the line in your script which assigns a value to the field on which the Calculate event was fired should *always* be the *last line* in your script. This is because the last-executed line in your script is the one that the XFA Object Model will use to determine the value of that field.

While it’s generally not recommended to do much more than set a field’s value in the Calculate event, reality is that most of us use it for much more than that: Since it fires on all fields on a form after a field’s value changes, we may use it to affect the presence, color, dimension, etc., of some fields which depend on the values of other fields. Therefore, it’s very easy to fall into this trap where your calculation script isn’t working probably simply because you haven’t structured it correctly.

Continue reading…

Data-Nominated Subforms

I thought I would post a little sample on data-nominated subforms tonight. This is a new feature, introduced in Designer 7.1, which can be a very powerful tool.

Since the feature essentially lets you define expressions against values from data being loaded into a form in order to control which subform, from a specified set (subform set containing subforms), will be used for the record currently being loaded into the form, you can do very interesting things. For example, you might have a table which lists data. Maybe you would like to use a row which has a yellow background to identify data which is not important, one with an orange background for data that’s important and one with a red background for data that’s very important. This can be easily achieved using Data-Nominated Subforms.

I’ve created a little sample based on the movie data I used for the “Conditional Breaks Sample”:http://blogs.adobe.com/formbuilder/2006/05/conditional_breaks.html I posted a few days ago. In this sample, I have a subform set which contains 3 subforms, each capable of binding to a movie record. The twist is that I want to use the green subform for comedies, the red one for action movies and the blue one for dramas.

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

*Minimum Requirements:* Designer 7.1, Acrobat Pro 7.0.5.

*Note:* A basic understanding of Data Binding is required for this sample.

Continue reading…

Conditional Breaks

Some of you have requested a sample of the new Conditional Breaks feature in Designer 7.1.

This feature allows you to set conditions, based on imported data, which determine when breaks should occur.

For example, you may have data that you want to list by category and every time the category changes, you’d like to start the new category on a new page. Or, you may have a separator that you want to insert in between sets of data on your form.

I’ve created a little sample which demonstrates the Conditional Breaks feature by listing some movie data where each time the category changes, a new page starts. Don’t forget to import the data.xml file into the form when you open it in Acrobat.

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

*Minimum Requirements:* Designer 7.1, Acrobat 7.0.5.

*Note:* A basic understanding of Data Binding is required for this sample.

Continue reading…

Samples! Give Me Samples!

One of the best places to look for Designer samples is on the “LiveCycle Designer Samples Site”:http://www.adobe.com/devnet/livecycle/designer_samples.html. There, you’ll find lots of samples demonstrating various Designer techniques and features.

Although new samples are constantly be posted to the Designer Samples Site, they can’t always cover all topics or address all of our customer’s questions/issues. As such, I’ll be posting some of my own samples to my blog. Look for them under the *Samples* category.