At the end of an orchestration, I am using the "generatePDFOutput" service to transform the xdp file into a pdf and then store it on the file system. The xdp form has a lot of form initialization, depending on its status at the time the form is opened, and it also has a lot of show / hide presence settings.
The orchestration completes successfully and writes the file to the file system. But when I double click on the newly-created pdf file, none of the show / hide presence settings appear properly (everything is shown, nothing is hidden).
The file opens with acrobat 8 professional because that's what I have, but I imagine it may also be opened with reader if someone with only reader accessed the file.
Is this occurring because acrobat 8 pro does not recognize the form initialization script? the show / hide settings? If so, what's the process one should use when using the generatePDFOutput service?
For what it's worth, here are the specific settings in the output service:
I think its because you are not maintaining the state of your form. On the Form Properties/Defaults page there is a setting to save form state automatically .....try using that one and see if it helps. Here is a creen shot:
Is this a form that a user interacts with then passes on to Output or is it going directly into Output? Can you describe the use case a little bit?
Yes, Paul, a user initiates the form in workspace, completes it, and when
submitted, it goes to our "back office". At that point all fields are
locked (thanks for that marvelous lock fields code), and the back office
person simply reviews it and then marks it completed. At that point it is
archived to the file system (later to be archived to FileNet, but not
When we pull up the file when it's been archived, that's when the form
looks bad. It's archived to a pdf, and show/hide settings don't stick.
I can send you an archive, but it would include my mock up search web
service, a data file, the orchestration, the form, and some fragments. But
I'm willing to do so if you want to take a look-see.
Amal K Schmitz
Comerica Bank - Senior Applications Engineer
3701 Hamlin Road - Auburn Hills, MI 48326 - Mail Code 2460 - 248.371.5079
(Judge Judy Rocks ) Please consider the environment before printing this
email and be aware that if you reply directly to this particular message,
your reply may not be secure. Do not use browser e-mail to send us
communications which contain unencrypted confidential information such as
passwords, account numbers or Social Security numbers. If you must provide
this type of information, please visit Comerica to submit a secure form
using any of the "Contact Us" forms. In addition, you should not send, via
e-mail, any inquiry or request that may be time-sensitive.
If you receive this e-mail by mistake, please destroy or delete the
message and advise the sender of the error by return e-mail.
In File-Form Properties, under the Performance tab, I have "Form requires
server-side data binding and / or scripting" selected.
I think we do need server side data binding (don't we? ) because we use a
"search subsystem" fragment on the form that utilizes a web service to
search data against a back end mainframe, then populate the form with data
after the user selects a customer.
In nay script that is written on any event in the top right corner of the script editor there is a dropdown that controls where the script is intended to be executed. It is client by default, did you modify any of these to run serverside?
No, I ran through the form and they are all client-side.
The show/hide settings are set on form init. Here's a snippet of code:
//only new docs should show search
app.alert("not new!"); <-- this executes in workspace but not when archived to pdf and opened from the file system
commonScript.setAllFieldAccess(root, "readOnly"); <-- This seems to work, you can't edit the fields in the pdf
mainContentSubform.resolveNode ("commentsBackOfficeFrag.comments").access = "open";
At the point the file becomes a pdf and is on the file system, the formStatus value is "submitted" (this has been verified by making the status field visible throughout the whole orchestration).
Perhaps I'm not understanding... Will acrobat execute form initialization script that was created from a designer xdp file?
The app.alert doesn't execute when I open the pdf.
Here's a snippet of the form where the presence is not working when the pdf is opened from the file system:
The code will not run serverside unless you mark the script to run client and server. The app.alert will cause an error server side so comment it out. The form init events will run server side so you should be OK there. If there are issues with the script the will appear in the server log. At 1st glance it looks Ok to me (except for teh app.alert).
Well, I tried both "Client and Server" and "Client" and I'm not making much headway.
Error: Invalid property set operation; subform doesn't have a default property
I am not sure why there seems to be an error on this line of code when the form is in workspace, but the same form works great in designer "preview"...
So the main page calls initForm() exactly as shown above, and my initForm() method has had its code reduced to just about nothing.
Could it be related to using Acrobat 8.1 professional to open the pdf?
I have attached an archive with the sample form and process if anyone would be so kind...
Can't upload the archive. Get an "unauthorized" error: