Posts in Category "Debugging"

Previewing as Dynamic PDF

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”:http://blogs.adobe.com/formbuilder/scripting/instance_manager 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~

Debugging Scripts

p. Here’s a simple tip that could make a huge difference in your ability to debug your scripts in Designer:

p. If you use the JavaScript language for a script, you can use the following function to output information to the Acrobat Console:

bc. console.println(“string”);

p. Anyone who has attempted to debug their script(s) in Acrobat knows that it’s a painful thing to do. Unfortunately, many only know about

bc. app.alert(“string”);

or

bc. xfa.host.messageBox(“string”);

p. which gets the job done but not without some headaches and, in certain cases, RSI in your index finger! The other problem is that showing a message box can cause differences in the form’s behaviour especially if you’re trying to debug a script which is setting focus to an object on your form. The fact that a dialog is displayed can really mess things up.

p. By using console.println, you can output text to the Acrobat Console (when in Acrobat — even Preview in Designer — just press Ctrl + J to display it) so that you don’t change the behaviour of your scripts.

p. The ability to debug scripts is something we know needs serious attention in Designer and trust me, we’ve talked about it and we have plans to address these issues but I can’t speak about anything definite at this time.

====
~*Updated:* November 1, 2006~