I have a large, complex form that has several subforms that I need to have zero instances the first time the form is opened. Most of those subforms that I set the initial instances = 0 on the Object pallet do exactly that--they behave and open with zero instances! However, I have one subform that always starts with an instance (1 instance instead of zero instances). I really don't want to work-around this, as I have done in the past when this has heppened. I want to solve it.
I have tried
I have encountered this sort of thing before and finally gave up and used the "presence" property as a work-around. The subforms don't always get utilized by the user and they should only exist when the user needs them. I will be exporting the XML data out of this form and exporting a lot of empty elements just presents another problem I'd like to avoid.
Any suggestions are most welcome. I hope someone knows of a solution--I have spent way too much time on this.
Are you pre-merging data with that subform when it opens? Although the minOccur=0 in the template, you may have an instance of that subform in the data, and therefore a copy will be forced to lay down.
As well, do you have a schema assoicated with your form? Schema may be forcing an instance as well.
Thank you for considering my problem and posting your questions. I am not merging data and I have not associated a Schema. No Data Connection has been set up, yet. Any bindings are "Use name".
Perhaps this will help:
I will call the subform described above: mySubform
Regarding this.parent.parent of mySubform
When an instance of this.parent.parent is added,
I hope this will shed some light on what's going on. There are scripts on process events that I use to control the presence of subforms and fields as well as toolTip values. The instances of subforms however, are controlled by scripts fired by interactive events.
What target version is your form set to (default tab in form properties)?
In this case, if I have target version to be 9.1 or later.
The following heirarchy in a simple layout:
If I render this pseudo template in Acrobat/Reader 10.1.3, I do not see the TextField, which is contained in MySubform. If I set MySubform to have a minOccur of 1, then I see it. I do not have any script on the form.
To me this is working as designed, unless I have misinterpreted your scenario, but it could related to behaviour based on your target version.
The target version is set for Acrobat/Reader 10.0 or later.
Here is the scenerio:
Right now, when I open the form, I get: GrandParent.Parent.mySubform.TextField1 (I see TextField1 and that is not what I want)
And when I do Grandparent.addInstance(1) I get: GrandParent.Parent.nothingElse (I don't see mySubform.TextField1 in the new GrandParent. Great! that is as it should be).
Why if I add an instance it behaves correctly? but not when the form first opens?
I have another Subform in this form that does min="0" correctly.
For mySubform, I observe Designer actually removing my manually added edits to the <mySubform><occur/></mySubform> element. I don't normally manually edit the <occur/> element in the XML, but I have in this case, in an attemp to fix the problem. I'm thinking this may be a bug--along the lines of the "small-script-edits-disappear" bug.
I can not reproduce this behaviour either though I am still using Designer ES 9.0 and don't have a target version or Acrobat/Reader 10.0.
Is it possible to post your form somewhere so I can check I understand the problem.
In designer UI, set the binding to repeat for mySubform, but leave the checkBoxes unchecked:
You should see the following XML for mySubform:
<subform name="mySubform" w="100mm" layout="tb">
<field name="TextField1" w="62mm" h="9mm">
<font typeface="Myriad Pro"/>
<margin topInset="1mm" bottomInset="1mm" leftInset="1mm" rightInset="1mm"/>
<?templateDesigner expand 1?>
<occur min="0" max="-1"/>
This should produce the result I think you expect.
I have the checkBoxes unchecked and the occur element is <occur min="0" max="-1"/> .
Actually, this is the way the checkBoxes and XML have been all along and the results are what what I have previously described.
One of my attempts to fix this was manually adding the "initial" attribute to the <occur/> element (by directly editing since it won't stick in the Object pallet)
<occur min="0" max="-1" initial="0"/> that the edit reverts to <occur min="0" max="-1"/>.
Also I have tried
<occur min="0" max="1" initial="0"/> this is what I really want (max="1") and it reverts to <occur min="0" max="-1"/> as well
<occur min="0" max="1"/> reverts to <occur min="0" max="-1"/>
The documentation for scripting the "initial" property of an object says:
"This property should be used only for printed and static forms."
This doesn't make sense to me because static forms don't have repeating containers, so why would you need/use it?
Finally, to rule out that there is a script or property within mySubform causing this, I have set the presence property for all the subforms contained within mySubform to Inactive (Exclude from form processing) leaving only a single static object to be rendered if there is an instance of mySubform. (Bruce, I am not sure you have this on LCD 9. It is in ADEP Designer 10 and is supported by the target version). The result is the same--I see the first static object GrandParent.Parent.mySubform.staticObject but when I add a GrandParent I see GrandParent.Parent.nothingElse -- the added GrandParent doesn't have a mySubform. So it only misbehaves when the form is first opened, not when a GrandParent is added.
I have removed global bindings from the few objects in mySubform that have them--no change. I have commented out the 1 script in mySubform that runs at form:ready--no change. I am going to look at scripts outside mySubform that get values from objects within mySubform, to see if somehow that is where the answer is. I would think that scripts would impact new instances of GrandParent, as well. I've looked at all other form:ready scripts and none interacts with or get values from mySubform.
I think I may just have to settle for a work-around. Sure would like to know whats going on here, though.
I'll admit, I am confused by your result as well. You shouldn't have to set the initial property to make this work.
I am using Designer 10 (ES3), and am Rendering the XDP to PDF in Acrobat 10.1.3.
Perhaps it is the reader version here?
Can you share your form on acrobat.com?
I'm sorry. I can't post my form to a public place. Even if I could share it, I think it highly unlikely that someone would have time to carefully examine the form (it contains 1000's of objects and has 80,643 lines of XML). Besides, the answer is figuring out what happens during the original layout, that doesn't happen with initiation of a new instance? That is, understanding the form processing better will help to determine where to look to find the cause.
Just now, as an experiment, I added a button that has the following script:
The button adds a new instance of mySubform. Wow! that is not what I was expecting. I was hoping it would remove the unwanted instance of mySubform.
Hope that provides a clue for someone. Any suggestions are much appreciated
Sorry. did you or did you not reproduce this with a simplified version of your form?
Reader will interpret the initial design layout as you see it in Designer, unless altered via script at runtime.
I cannot reproduce what you are claiming in a simplified sample. I suggest logging a ticket with Adobe Enterprise support, so your form can be inspected ( since you cannot share it to a public place.)
Thanks!did you or did you not reproduce this with a simplified version of your form?" I had tried some simplifications, using "Inactive" presence--but that didn't flesh out the problem.
the name of either one of the
Glad to help and see you passed the issue!
As you have just dicovered, with automatic or implicit binding (Use Names), 'like' names are significant, whereas 'unique' names are not in the binding process.
Europe, Middle East and Africa