Just to say that this kind of quick how-to article is a real help – thanks!

Andrea,

The problem you’ve run into is similar to the problem others have when attempting to set focus to a particular field after validating the field from which the focus came.

As you said, the Host Model doesn’t know about the new page that you just made visible immediately after you’ve set the page’s presence to “visible”. Therefore, you need to delay your call to xfa.host.currentPage until the host has been updated.

You can do this by using the following line of JavaScript code in the button’s Click event (the button which sets the presence of the page):

app.setTimeOut(“xfa.host.currentPage = 2;”, 10);

This script will delay the call to set the current page to the third page (page indexes are zero-based) by 10 milliseconds, just long enough for the host (Acrobat) to react to the change in presence and update the Host Model.

Andrea,

Your latest question sent me on a bug hunt! You are correct in thinking that you need to place the call to “xfa.host.setFocus” in “app.setTimeOut” as well. There’s a bug in Acrobat 8.0 which prevents “xfa.host.setFocus” from functioning properly when setting focus to a field immediately after showing the hidden page on which it is located.

Note that when using “xfa.host.setFocus” in an “app.setTimeOut” call, you’ll have to give the full SOM expression, not just the field’s name:

app.setTimeOut(“xfa.host.setFocus(‘” + Page2SF.TextField1.somExpression + “‘);”, 10);

Also note that if you’ll always be setting the focus to a field after showing a page, you don’t have to set the current page since setting focus will cause Acrobat to scroll to the appropriate page automatically.

Andrea,

Unfortunately, I’m having a difficult time reproducing the behaviour you’re seeing when you include a Paper Forms Barcode on your form.

Have you setup the barcode to encode fields in a collection? Is the encoding in XML or tab-delimited? Are you doing this with Designer 7.1 or 8.0?

Ken,

Assuming you have a “delete” button on each subform instance and you want focus to go to the “name” field of the previous instance when the user clicks on the “delete” button to remove a particular instance, you simply need to get the instance number (i.e. the index) of the previous instance, get a reference to that instance and set focus to the “name” field which it contains.

Here’s an example in JavaScript (you would place this script on the “delete” button’s Click event):

// index of the previous instance (“parent” is the repeatable subform)
var nPrevIndex = this.parent.index – 1;

if (nPrevIndex >= 0)
{
    // we can safely set focus on a previous instance
    var oPrevInstName =
      xfa.form.form1.resolveNode(“AddressSF[” + nPrevIndex + “].Name”);

    // set focus to previous instance’s “name” field
    xfa.host.setFocus(oPrevInstName.somExpression);
}

// remove the current instance
xfa.form.form1._AddressSF.removeInstance(this.parent.index);

Note that this script assumes the repeatable subform’s name is “AddressSF”, that it contains a field named “Name” and that it’s being executed using Acrobat 8.0.

If you’re doing this in Acrobat 7.0.x, you may need to delay the “xfa.host.setFocus” call with an “app.setTimeOut” call if the focus doesn’t go to the “name” field:

app.setTimeOut(“this.getField(‘” + GetFQSOMExp(oPrevInstName) + “‘).setFocus();”, 10);

Andrea,

I’m sorry: I should have also asked you what version of Acrobat you are using.

I set the same settings on the paper forms barcode in my test form but still couldn’t reproduce what you’re seeing.

In order to investigate the problem a little more, you could also try removing some, but not all, of the objects from the collection being used by the barcode.

It’s not surprising that performance drops once you start using the barcode, especially if the collection includes a large number of fields to encode: Everytime a field’s value changes, the barcode’s script must re-encode values from all fields in the collection since it can’t change only the value of the field whose value changed (and neither does it know the specified field whose value has changed). If there are a large number of fields to encode, it’s possible that this drop in performance is causing a timing issue which is preventing the “app.setTimeOut” call from functioning correctly.

Let me know what you find and we’ll take it from there.

Stefan,

Quick question. I saw some setFocus comments here so thought I’d try.

In my Validate Event using Adobe Reader 8.1.0 or higher, I’m using:

xfa.host.setFocus(); // Clear focus operation
xfa.host.setFocus(this); // Set cursor back to current field

This sets the cursor back to the current field when bad data is entered and works for both the Tab and Enter key. It highlights the bad data.

But this does not work correctly when using Adobe Reader 8.0 and 7.0.x.
Problems I had with these older Readers regarding setFocus:

1. Enter key does not fire setFocus, only Tab works
2. setFocus goes into loop when using a Date/Time field and Reader 7.0.x
3. xfa.host.setFocus() does not clear focus operation like Reader 8.1.0+

Anybody else had similar problems or know a workaround?

Thanks,
Ron

Ron,

In my experience, the Validate events are unreliable and in need of fixing. We’re already thinking about solutions for this in a future release.

As for the focus issues, the behaviour of xfa.host.setFocus() changed in a recent version of Acrobat/Reader — it may have been the 8.1 release. The major change is that the call to setFocus() used to occur after the current event script was finished executing (i.e. it was postponed until later). This was causing problems such as the inability to set focus back to a field on exit if it contained invalid data (which sounds like what you want to do) because by the time the setFocus(this.somExpression) was executed, the focus had already changed to the next field in tab order. Now, the setFocus() call is executed immediately which means you get the behaviour you expect.

I would recommend you check for invalid data in the field’s Exit event which is fired whether the user presses the Enter or Tab key or clicks away from a field. If the value entered is invalid, just call xfa.host.setFocus(this.somExpression). The Validate event fires any time a dependent field’s data changes which could cause you to set focus to the wrong field in certain cases.

Hi Stefan,

I’d like to ask you, please, explain how you are forcing the user to enter a valid data in a field without leaving it.

Thank you very much,
Dawid

Hi Stefan,

I need to place a Save button on my PDF form which saves the Form when any field is filled. I get articles related to SaveAs button option. But i want just Save option button. Please help me out in fixing this issue..