Problem automatically print

[ida_raski]

Hi, I have a problem with the printing of my form.

We want to be able to show the print dialog automatically when the form is opened.
The problem is that the print dialog selects a print range from 1 to X and when I select
the range 'All' the X value increases with a couple of pages. So, is there a possibility that when
the function xfa.host.print(...) is called, the layout changes and the pagelength grows?
The default value of the print dialog should be 'All'.

You can have this selected when you do 'xfa.host.print(1, "0", (xfa.host.numPages -1).toString(), 0, 0, 0, 0, 0);'.

But because of the total page change it selects 'From 1 to X'.

Does anyone has an idea how I can resolve this?

So how you can have the right value of the numPages during printing?

Thanks in advance!

[Niall_O_Donovan]

Hi,

What event do you have the script in? Try the docReady event - this is late in firing when the form opens and the form should be laid out when the docReady event fires.

N.

[ida_raski]

Hi Niall,

Thanks for your answer.

But the script is already in the docReady event.

The weird thing is that when you hit Ctrl+P the print dialog is set to 'All'.

And when you do the print job twice from scripting, the second time it also is set to 'All'.

[ida_raski]

I have taken a couple of screenshots..

The first image shows when the script from the docReady event is being called.

You see I'm getting the option 1-20 selected and in the toolbar I can see 1/25, this doesn't make sense.

The second image shows the situation when you do Ctrl+P.

The option 'All' is selected and it also shows 25 pages.

We just want that the option 'All' is default selected and al pages are print so the end user only needs to click Print and nothing else.

Anyone ideas?

Thanks in advance.

Kristof

[Niall_O_Donovan]

Hi Kristof,

I have tried it here in a fairly straightforward form (14 pages with 5 hidden). While the form is dynamic, it is not connected to a database and it does not have fields that grow to accommodate data when it is opened. The print script in the docReady event works.

I suspect that your form has fully rendered when the script fires.

Try an app.setTimeOut to delay the print script firing a short time after docReady, say for 100 miliseconds.

If you have a print button, then something like this in the docReady event of the form1 node:

app.setTimeOut('myPrintButton.execEvent("click");', 100);

Hope that works,

Niall

[ida_raski]

Sorry Niall, that doesn't work either.

The form is also dynamic, but not connected to a database.

The form gets filled op with xml data and their are subforms which dynamically grow considering the data.

Maybe I can send you the form so you can simulate the problem?

[Niall_O_Donovan]

Hi,

Try this: https://acrobat.com/#d=5dv7lpeqEVtr1BJCUh6YHw

If that doesn't work, try uploading your file to Acrobat.com or a file sharing site and then post the published link/URL here.

Niall

[ida_raski]

Thanks Niall,

That doesn't work either. But I know now what is causing this.

It has something to do with the prePrint scripts, when I disable them all, everything works fine.

So I'm trying to create a workaround now. If this doesn't solve things, I get back to you!

Thanks for all the help so far.

Regards

[ida_raski]

Ok, so far I got no solutions.

I was trying to put all the prePrint scripts in a custom function with the print statement at the end.

Then when the form is opened I tried to call this function.

But I keep getting javascript errors that certain fields 'has no properties', strange because they have.

Is my attempt a good try or do you know a better solution.

Sorry but I could not upload my form to Acrobat.com.

[Niall_O_Donovan]

Hi,

I am not sure if I would put the prePrint functionality in a function, but that aside...

You may be getting those errors if you have unnamed pages and subforms. Try making sure that all objects are named first and then reference the objects correctly in the function.

Try that and come back if you are still getting errors.

Niall

[ida_raski]

Hi Niall,

Here I am again.

My solution, writing the prePrint statements into one function, did work on my local machine.

However it did not work for the client. The form is opened from a .NET application and still has 'From 1 to X' selected.

It is first Reader Extended with Reader Extensions 7 than certified and later opened with Adobe Reader 9.0. Could the problem be in those steps perhaps?

This really is akward behaviour, hope that this is'nt a sort of bug...?

Regards

Kristof

[Niall_O_Donovan]

Hi Kristof,

Without seeing the form it is difficult. Try increasing the time (milliseconds) in the app.setTimeOut script.

I would not have expected the reader enabling or version to affect this.

Sorry I couldn't be of more help,

Niall

[ida_raski]

Hi Niall,

I managed to upload it, you can find the form here: https://acrobat.com/#d=UsjceHMN0Lr6ah16G2mcWg

Regards.

[Niall_O_Donovan]

Hi,

Firstly, I see the event calling the function, but it includes an importData, specifying the XML file.

...
else
{
     xfa.host.importData("XML\\Exchange.xml");
     FormFunctions.preparePrint();
}
...

I think that this is now restricted for security reasons, as the user is not aware of or in control of the XML import. This may be your problem, that the script is failing here and not at the print command.

Next I don't think your syntax is correct for the digSig variable. The 'getField' is core/AcroForm javascript and even if this is correct, you are using 'this' in the signature object reference. 'this' means different things in AcroForm/core javascript (this = the document) and XFA javascript (this = this object).

I haven't really gone at checking the status of signatures, but I think that this is where your problem is:

• digSig variable; and
• Silent XML import.

Hope that helps,

Niall

[Niall_O_Donovan]

Here is an example:

https://acrobat.com/#d=Paj9XDR-8TOixSVXrYrX9g

N.

[ida_raski]

Ok Niall, thanks a lot.

I'm not able to recreate the situation now locally but I'll provide this information to the client.

Maybe this will help. I still have one question: if the problem resides in the use of importing the xml, should an setTimeOut solve this?

I'll post an update on this issue tomorrow..

Regards.

Kristof

[Niall_O_Donovan]

Hi Kristof,

No setTimeOut will not help with the importData.  From the help file:

So, if you want to specify the XML file, then you will need to certify the form and distribute/manage the certificate.

Good luck,

Niall

[ida_raski]

Hi Niall,

Back again.

I certified my document etc. and did a couple of tests.

And recreated the behaviour in different cases. I can send you my documentation later on if needed.

Are you 100% certain that this isn't a bug with the print dialog interaction? Otherwise I will open a ticket at support.

Thanks.

[Niall_O_Donovan]

Hi Kristof,

I can't be 100% certain it is not a bug, but I really think that it is a scripting issue. For example if you open the JavaScript Console in Acrobat (Control+J) and then open your file in Acrobat you will see an error in a docReady event:

Solve this and I think you will be closer to solving your problem.

Good luck,

Niall

[ida_raski]

Hi Niall,

The screenshot you showed is solved in my newer version.

I'll send you my test documentation later on if you like to see it.

I really think it's a bug. We've watched it internally and even the LiveCycle experts think it's really strange behaviour.

Regards.

Kristof

[Niall_O_Donovan]

Okay Kristof, if you post it to Acrobat.com,

Niall