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

Here are some of my memories of Phoenix:

Scottsdale was a really nice place to shop!

A cactus almost as tall as a palm tree! Back home, a cactus is considered a bonsai since they don’t grow to be more than 2 inches tall.

This flower seems to be everywhere on the side of the roads in Phoenix — beats the dead brown bushes and ashphalt we have on ours…

The entrance to the Adobe Vendor Suite at the symposium hotel.

This was where the symposium took place — a really nice resort with lots of family-oriented activities.

Cameron, AZ. Who knew there was a town named after me? 😉

The Grand Canyon — pictures don’t do it justice! Absolutely spectacular!

Another view of the Grand Canyon.

---

Posted by Stefan Cameron on May 30th, 2006
Filed under BFMA Symposium,Conferences

---

There’s a bug currently logged against Acrobat 7.x where removing an instance of a dynamic subform, using the Instance Manager (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):

_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();

Calling the Form object’s remerge() method will “force the remerging of the data model and template model to re-create the form model”, as explained in the Adobe XML Form Object Model Reference. This means that the form’s current data set will be remerged with the template (the form objects like dynamic subforms, fields, etc.). The result will be a form that looks exactly the same as it did in its state just prior to calling xfa.form.remerge() but with all IMs properly updated to the current number of dynamic subforms which they’re managing, thus correctly updating each IM’s count property.

Even if this problem is addressed in a future release, you’ll want to check the version of Acrobat that’s running your form in order to know whether it has the fix or not (in JavaScript as follows):

// get the host's version as a string and split it into an array
var oVerArray = xfa.host.version.split(".");

if (oVerArray[0] == "7")
  xfa.form.remerge();

Or more simply:

if (xfa.host.version.split(".")[0] == "7")
  xfa.form.remerge();

---

Posted by Stefan Cameron on May 25th, 2006
Filed under Instance Manager,Scripting

---

Here’s a little something that very important to know when working with dynamic subforms and using their Instance Managers (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.

Note that this issue was addressed in Acrobat/Reader 8.0. Therefore, if your form targets this version (or later) of Acrobat/Reader, you shouldn’t need the recalculate() workaround.

Download Sample [zip]

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

Updated Nov 19, 2009 — Added note about the issue being resolved in Acrobat/Reader 8.0+.

---

Posted by Stefan Cameron on May 20th, 2006
Filed under Instance Manager,Scripting,Tutorials

---

I’m very excited to be attending the BFMA’s 37th International Symposium on Forms and Business Processes 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.

---

Posted by Stefan Cameron on May 20th, 2006
Filed under BFMA Symposium,Conferences

---

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:

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

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:

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:

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 (located in the XML section).

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

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

And in FormCalc:

(theField.isNull | theField == "")

---

Posted by Stefan Cameron on May 19th, 2006
Filed under Scripting

---