Change subform height at compile time ?

I'm not sure what you mean by compile time? LiveCycle forms are not compiled. You create them in LiveCycle Designer and then open and use them in Acrobat/Reader. I think you must mean at Load time? That's one of the times when the Page ready event is triggered.

If you want to affect the height of all of the repeated subforms you have to explicitly set the height of each one. There are two approachs to this.

1. From a script in an element above the repeatable subforms use the resolveNodes function to find all instances. And then loop through them to set the height.
2. Form a script on the repeated subform the hieght change can be applied directly to "this"

You might want to watch this video on scripting subforms:
https://admin.adobe.acrobat.com/_a200985228/p87746471/

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Then most important JavaScript Development tool in Acrobat
[url=http://www.pdfscripting.com/public/34.cfm#JSIntro][b]The Console Window (Video tutorial)[/b][/url]
[url=http://www.acrobatusers.com/tutorials/2006/javascript_console][b]The Console Window(article)[/b][/url]

Thanks for the reply thom, I will look into that. I think at one point I tried (2) but couldn't work out how to reference a node in the XML properly.

Today I also looked into the possibility of using a choice subform set which I got quite far with and almost got working completely other than (a) it would intermittently not choose the right sub form and (b) for some reason, despite there being 12 slot nodes in the XML, it would skip the first one :(

Are there any tutorials on using choice subform sets correctly ?

Say for example, that for option #2 you use the form:Ready event of the Repeated subform. In the script, that repeated subform is referenced with "this". So the height of the subform would be set like this.

this.h = "2 in";

You don't really need to use subform sets, or choice subform sets for this. Setting the height using one of the options I've already layed out should work.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Then most important JavaScript Development tool in Acrobat
[url=http://www.pdfscripting.com/public/34.cfm#JSIntro][b]The Console Window (Video tutorial)[/b][/url]
[url=http://www.acrobatusers.com/tutorials/2006/javascript_console][b]The Console Window(article)[/b][/url]

Thanks Thom, that sounds like a very workable solution - and makes more sense than having a choice subform set [ which we couldn't get to work anyway ;) ] with all 3 'choices' containing exactly the same info, and so needing to make any layout changes 3 times.

Presumably I can do something like

this.h = this.formHeight.rawvalue;

and then store the required height in a hidden text field, called formHeight, in each subform ?

However, on the subject of choice subform sets - I could still do with any links/tutorials you might know about.

On another PDF, we have a section of the page which needs to show one subform or another based on what is in the XML. I have both the subforms setup as required and they show correctly in the PDF (when not using choice sets) but I can't get the choice stuff to work (either in "named subform" or FormCalc expression mode). All I want to do is display subformA if the XML document has a particular node in it other display subformB. But no matter what I try, it won't work :(

I think you are a bit too hung up on the XML. It's much more productive to deal with form elements and thier properties from the top down. After all this is a Form. XML just happens to be the underlying structure. For the most part the system deals with it automatically and it only needs to be manipulated directly for a special case.

For example, it is the rare situation where the subform height would need to be adjusted through explicit code. There is a very rich set of features in the LiveCyle model for automatically resizing and placing subforms. And since subforms are container elements that are usually invisible to the users, it's more likely that you'd need to use code to resize the form fields, which would automatically resize and reposition the containing subforms.

On another note. It seems that you're pretty enthusiastic about this form and eager to get more information on LiveCycle scripting. However your explainations are not very clear. It's best to stick to a single point topic and fully explain the setup and where you want to go with it. The narrower the topic and simpler the explaination the more likely you will be to get good info.

So in your post tell us about the form behavior you'd like to see based on form properties. Don't talk about the underlying XML unless it's specifically relevant, which it usually isn't.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Then most important JavaScript Development tool in Acrobat
[url=http://www.pdfscripting.com/public/34.cfm#JSIntro][b]The Console Window (Video tutorial)[/b][/url]
[url=http://www.acrobatusers.com/tutorials/2006/javascript_console][b]The Console Window(article)[/b][/url]

Thanks for the help Thom - most helpful.

It would probably have been wise to state, in the OP, how we use LiveCycle. We basically use it as an upgrade to Cold Fusion Report Builder in that the user has no control over the content in the PDF - which is also generated from database/xml data and placed into read only text fields, images, etc. We generate some XML data which we then pass to a LiveCycle PDF which, in turns, produces the end result. Hence my 'hang up' with the underlying XML [ I am not too interested in the XML behind the PDF form, but rather the XML data which the PDF is being bound to ]

It has been a fairly long learning process and we have found a few niggles such as (a) LiveCycle not appearing to have a 'Print Control' property ie show/hide an element on the form based on data and (b) not being able to bind an image field's url to data (I understand this has been 'turned off' in a recent version of Reader as it was deemed a security risk). Both these things were relatively simple in CFR but ... we are getting there slowly.

In a long winded, roundabout, way I guess what I am saying is - we probably don't use LiveCycle in the way it is intended ie interactive, client-side, forms - but it was 'sold' to us as the best upgrade from CFR.

Ahh, now it becomes more clear. I was thinking you had an interactive form. So let me get this straight. You have a LiveCycle form template on the server. Data is loaded into this template on the server side using CF. Then at some later time it's pushed up to Acrobat on the client side. But the basic data merge into the form template isn't doing the trick. In order to get the form to render properly in Acrobat there has to be some JavaScript to fix it up at load time. This fix up is a one time operation because the whole form is read only and will not change after it's rendered.

Ok, then the only events I would think you need to worry about are Initialize and Form Ready. From data on the form you should be able to fix it up pretty easily. Although I'm not sure how you'd deal with images.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Then most important JavaScript Development tool in Acrobat
[url=http://www.pdfscripting.com/public/34.cfm#JSIntro][b]The Console Window (Video tutorial)[/b][/url]
[url=http://www.acrobatusers.com/tutorials/2006/javascript_console][b]The Console Window(article)[/b][/url]

Thom, you've got it exactly :)

When we were doing it with CFR we had a 'parent' report which contained 3 subreports (not the same as subforms in LiveCycle ... from what I understand more live Fragments in LiveCycle ES) and dynamically we hid of the 2 subreports. Since we can't do this in LiveCycle we now have 1 form and will change the heights to get the same effect.

The only solution we came up with re the images is 64bit encode them in CF and pass them as a data string in an XML node and bind the image to that node. It works well other than it makes the underlying XML file a lot larger than the CFR produced ones.

I wouldn't think that hiding or showing the subreports, (implemented as subforms), would be a problem, and how this is related to the heights? I'm sure I'm missing a big piece of you're setup.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Then most important JavaScript Development tool in Acrobat
[url=http://www.pdfscripting.com/public/34.cfm#JSIntro][b]The Console Window (Video tutorial)[/b][/url]
[url=http://www.acrobatusers.com/tutorials/2006/javascript_console][b]The Console Window(article)[/b][/url]

Ok. Each page in the PDF can have either 9, 12 or 15 'slots' (each slot contains an image and a over a dozen bits of other info) on it. But due to the design this isn't just a case of repeating the subform either 9, 12 or 15 times rather the 'slots' need to spaced evenly down the page (as either 3x3, 3x4 or 3x5). Note: the number of slots per page can vary from page to page in the same PDF.

So I either have (a) 3 subforms, each hard coded to the correct height, and then on form:Ready hide the 2 unrequired subforms on every page in the PDF or (b) 1 subform, which has "this.h = 'x in'" in it's form:Ready script.

I am guessing, from a server load and development/change control point of view, (b) is the better option.

So the arrangment is rows and columns? Then you're using Western Text flow?

I agree that setting the height with JavaScript is the better options. However, depending on the parameter that determines the subform hight, it might be better to make the subforms auto-sized. And then manipulate the size of elements inside the subform.

Thanks for the help Thom, got back to my desk this morning and the "this.h = ..." solution works perfectly.

Now to go off and get my head round getting subform choice sets working for one of our other PDFs ;)