Can't get subform to print from Reader

Is this script marked as FormCalc or JavaScript? If it is JavaScript, are you seeing any errors in the console window? An exception would abort the script. Is it only in Reader that it doesn't work, or in Acrobat as well?

I'd suggest testing the "xfa.host.print" line by itself.

On a general note, I've had lots of problems in the past with trying to set something as visible, printing, and then hiding it again. It seems that Acrobat doesn't always get the setting up to date before sending the doc off to the printer. There's a bit of a timing issue.

Hi Thom
The problem persists whether the form is run in either Reader or Acrobat. By "console window" I'm assuming you mean Acrobat menu bar Advanced>Document Processing>Javascript debugger? I've no experience with it, but it shows the following in the console window:
Acrobat EScript Built-in Functions Version 9.0
Acrobat Annotations / Collaboration Built-in Functions Version 9.0
Acrobat Annotations / Collaboration Built-in Wizard Functions Version 9.0
Acrobat SOAP 9.0

TypeError: Invalid argument type.
Doc.print:0:Field undefined:Mouse Up
===> Parameter nStart.
TypeError: Invalid argument type.
Doc.print:0:Field undefined:Mouse Up
===> Parameter nStart.I also tried your suggestion, running the form *without* setting docReady frontPageData.presence to hidden. xfa.host.print seems to work fine, both in javascript and in formcalc. So I guess your thought that its a timing issue is correct? As I said above, I tried to split up the code between prePrint, mouseUp and postPrint events, hoping it might stage events better, but it didn't.

Do you suppose there's some kind of basic time delay script I could include that might allow Reader to "catch up" so to speak?

It looks like one of the issues is that the Acrobat doesn't like the starting page number. Is this a one page form? In that case, the start and end should be "0". Which is the number of the first page.

As for the visible/hidden issue. You could try using a timeout script to perform the print. Place the visible code in the MouseUp event as well as the timer start code. The timer script would then call print. Place the hidden code in the post print event.

Like this:

frontPageData.presence="visible";
app.setTimeOut("xfa.host.print()",500);

However, I'm not sure its a strict timing issue. It could be that you have to wait until the layout is refreshed, which may not occur until after the mouseUp script exits, i.e., Acrobat can't begin to recreate the layout until after the mouseUp event completes. In this case you could try using the layoutReady event to perform the print.

So the MouseUp event would use code like this:


frontPageData.presence="visible";
event.target.doPrintVar = true;

Where event.target is a pointer to the document object, so "doPrintVar" is a document level variable being created on the fly.

Then use this code on the LayoutReady event:

if(event.target.doPrintVar)
xfa.host.print();

event.target.doPrintVar = false;

I'm going to give your suggestion a try, because what I've done in the meantime works... but only up to a point:

The form has multiple pages, but only one subform is visible at a time, with the exception of this printing phase. When subform prntInstr is visible it presents the user with 2 button objects, each containing the print script I have been working on: frontPageData and backPageData. So when either of the buttons is clicked, its associated frontPageData or backPageData subform becomes visible, therefore making it the second visible page of the form at that point in time. (prntInstr=page 0, and frontPageData=page 1 or backPageData=page1) Hense, xfa.host.print(1, "1", "1", 0, 0, 0, 0, 0).

What I did was spread events out even more than I had tried before:
mouseDown - front(or back)PageData="invisible" //works better than going straight from hidden to visible
prePrint - front(or back)PageData="visible"
mouseUp - xfa.host.print... etc.
postPrint - return to "hidden"
Like I said, this almost works. I can now initiate printing from both button objects. Problem is, they both print frontPageData. backPageData never appears in the Windows print dialog box, frontPageData appears when either button is clicked. I've triple checked my coding for the correct SOM's, and its driving me loopy.

So I'm trying your solution tomorrow morning, its getting late here, and I'll post my results.
I appreciate your staying with me so far. :)

Thom I'm sure you are on the right track regarding timing and allowing the layout to refresh. Unfortunately when I tried your changes I must have overlooked something else. When the form opens I get a Windows dialog box displaying a blank page ready to print. Then when I get to the prntInstr subform and click one of the two buttons to print, only the blank underlying master page becomes visible, but it takes a second click on the print button object to bring up the Windows dialog box, again showing a blank page.

So what I did was modify my script in my last post to make visible *both* frontPageData and backPageData on *both* print button objects. In other words, the same script on both with the exception of xfa.host.print() coded for either page 1 or page 2 respectively. So far its working. Apparently Acrobat, along with not being able to render the pages in time, also didn't like my using the same xfa.host.print() page number 1 for both front and backPageData, despite only one of the two subforms being visible at a time.

I really appreciate your time and patience helping me understand a little more about how these events work.

Congratulations on the progress you've made so far!! I think you are operating on the edge here.

One of the issues may be that there is a progression to the layout update. Events are traveling up and down the object hierarchy as Acrobat does it's thing. It may be important which object the print is triggered on, or LayoutReady may not be the best event. Try this. Add console.println() code to events on several objects at different levels of the hierarchy. Set the text so you can see which events on which objects are being run. Create a button that just makes the visibility change you are interested in (no printing). Then open the form in Acrobat, and open the console window. Press the button and watch the progression.

I think you can add app.alert() popups to different events to stop the updates on a specific event to see what stage the form is at. I don't know how well this will work, but it should give you a very good idea of what's going on.