I’m sure many of you out there have run into problems with fields on printed forms where the value entered in the field was too long to fit within the field’s visible area. The result is a black “+” sign on the lower left corner of the field — not much help in reading the entire content when it’s printed and you can’t scroll anymore:
What if there was a way to configure the field so that the entered value’s font size would automatically shrink to fit the value within the field’s visible area (down to a certain limit)? Of course, it’s possible the text may end-up too small to read without a magnifying glass but the entire content would be printed nonetheless (as long as the minimum font size wasn’t hit):
The trick here is to set the field’s value font to a size of zero (0) but it’s not as obvious as it may seem…
In Designer, there are two ways to do this:
The first is to use script in the field’s Initialize event (FormCalc in this case but JavaScript would do just fine too):
$.font.size = "0pt"
The second is to use the Font palette. In this case, however, only the value font’s size may be set to zero. Attempting to set the font size for the caption (or the caption and value combined) to zero won’t work. To specify the value font only, use the Selector widget at the top (highlighted in green on the image below) and pick the Edit Value item. Then, set the font size to zero (highlighted in yellow).
Posted by Stefan Cameron on July 26th, 2006
Filed under
Designer
Have you ever lived through the frustration of previewing a form on which you’ve written a simple little script to affect the presence of an object when a button is clicked and pulling your hair out because you keep clicking on the button and nothing happens (object doesn’t disappear, there’s no error message, etc.)? Or maybe you’ve been in a situation where you’ve added script to a button in order to insert a new instance of a repeatable subform and while clicking on the button doesn’t produce one, the submitted XML data file contains entries for each new instance that was added?
Even if you haven’t, it may happen someday so here’s the remedy for the case of the “Common (Static PDF) Flue”…
In Designer, there are two different locations containing settings which affect the type of temporary PDF file created when you click on the Preview tab:
- Under the “File Options” section within the “Document Handling” panel of the “Tools | Options” dialog, you can set the Default File Type for New Forms. This type is used on new forms which you preview prior to saving (because Designer doesn’t know which format you’ll use at the time of preview). This is set to a static PDF format by default.
- Even if you’ve specified a dynamic PDF format for the Default File Type for New Forms, this setting may be overridden by the Preview Type and XDP Preview Format properties in the “File | Form Properties” dialog in the “Defaults” panel once you’ve saved your form. The Preview Type property, set to “Interactive” by default, determines whether the form will be previewed as an interactive (dynamic) form or as a print (static) form. This property supersedes the PDF format. The XDP Preview Format property usually picks-up the Default File Type for New Forms setting and determines what PDF format will be used to preview your form should it be saved as an XDP. (Note that if you’ve saved your form as a PDF file, then the XDP Preview Format setting is ignored).
Now that we’ve covered the different properties which affect the PDF preview format, here’s how to kick that flue I was talking about earlier (so that you actually do preview in a dynamic PDF format and stop pulling your hair out):
- If you haven’t saved your form, make sure the Preview Type is set to “Interactive” and that the Default File Type for New Forms is set to a dynamic PDF format. You may also want to set the XDP Preview Format to a dynamic PDF format while you’re at it.
- If you’ve saved your form as a dynamic PDF, make sure the Preview Type is set to “Interactive”.
- If you’ve saved your form as a static PDF, none of these settings will help you. You must first save your form as a dynamic PDF.
- If you’ve saved your form as an XDP, make sure the Preview Type is set to “Interactive” and the XDP Preview Format is set to a dynamic PDF format.
- If you’re tired of running into these problems and want to avoid them in the future, just set your Default File Type for New Forms to a dynamic PDF format.
I hope this tip improves your form design health. It did wonders for me!
Updated: January 27, 2007
Posted by Stefan Cameron on July 24th, 2006
Filed under
Debugging,
Designer,
Scripting
For those of you still running Designer 7.0 or earlier, check-out the new stuff available in 7.1 on the Adobe LiveCycle Designer site.
There’s a “what’s new” link under the Learn More column.
Among my favourites are:
- New Table object — play with rows and cells to get really nice layouts.
- Dynamic Properties — automatically populate list objects with data from data connections.
- Paper Forms Barcodes — reduce data entry errors by encoding field values into a barcode which can be scanned from paper once the form has been filled, printed and manually signed.
- Conditional Breaks — use changes in your data to trigger breaks in your pagination (e.g. when the category changes, start the new one on a new page).
- Data-Nominated Subforms — use changes in your data to determine which subform should be filled next.
Posted by Stefan Cameron on May 5th, 2006
Filed under
Designer
