Frequently Written Answers by the LiveCycle Support team

Archive for August, 2010

When processing a template with data in one environment (in Output Designer for example, or on the development server), the output seems fine; but when the same data and template are tested somewhere else (a different Designer, a different Central server), the reult is that many pages are printed, some blank, some with data in the wrong place, some data lacking.

Solution #1 – the afxon option is not properly specified

This is most likely to be due to a single argument that has been omitted in your processing parameters : “-afxon”

From the Print_Ag.pdf documentation file:

To discard data for unknown fields, start Print Agent with the -afxon option.
To place data for an unknown field in the next field on the template, start Print Agent with the-afxoff option. This is the default.

In Output Designer, these options are set under menu [ Tools : Options : Print options ]. You can add here any number of command line arguments, separated by spaces, that will apply whenever Test Presentment is run.

In Central server, arguments can be placed at two different locations

1) In the Job Management Database

You can access this under [Central install directory]/Server/jfserver.jmd

Note the syntax of the JMD: the list of arguments holds on a single line, enclosed in quote marks. Within this string of characters, double quotes must be escaped by typing two consecutive double quotes.

I posted previously about checking JMD validity – if you have Python 2.x installed, you might want to try out the following: Tamble JMD 0.2a

2) In the data file

You can add arguments in the JOB line of your data file.

If the first line of a data file starts with ^job, the Central engine (if run using Central Control on Windows, or launching the jfdaemon or jfserver on *nix) will take the arguments listed and append them to the ones already extant in the JMD. Since they are applied afterwards, they take precedence.

So if you have an argument -afxoff in your JMD, and you specify -afxon in your JOB line, -afxon will be applied when processing.

Solution #2 – you are using non-SAP compatible templates on a Central activated for SAP data

You may find that the above solution does not seem to apply (but please, test that one first as it is the most likely). In which case, there is a second potential explanation.

Central Pro can be obtained with an SAP adapter which needs to be used with templates specially compiled for this use. To activate this special compilation mode, you need to set the value of the following key to “0”

Where ‘x’ should be replaced accordingly to correspond to your version of Output Designer. You can see in your problematic template whether the option is already active by looking at the template’s automatically generated preamble – if there are no !FldNotAvail events on the fields, the option is active.

Here’s a puzzler that looks strange, but that is easy to solve – once you understand a key difference between dynamic templates and static templates, and how Central loads and unloads tempplates.

Situation:
– You have multiple templates that you want to use for processing data
– You can process each template independantly without troubles (data only uses one template)
– When you call different templates (data uses the ^form command), with some combinations of files, you get the following error:Invalid options on ^subform command

Explanation:
Some of your forms are dynamic, some of them are static. Dynamic forms are created when fields are wrapped in subforms.

Dynamic forms, when compiled, create an embedded Preamble (see this in Output Designer with Ctrl+R, when a form is open)
Static forms do not.

The preamble is basically a set of variable definitions that get stored to a special global variable area.
Preamble variables call subform definitions, which are effectively the structural parts of the template.

When a template is loaded, preamble data is executed which reference form structures – for example, if you have a field called myfield in a subform called mysub, you will get:

When a new template is loaded, any pre-existing form structures are flushed from memory (the item referred to by the “\groupG_mysub\fieldmyfield” part) – but the global preamble variables (the “group:myfield!FldNotAvail” part) are not : they cannot be distinguished easily from regular data, so they are kept.

When you load a static form, no preamble data exists to overwrite previous preamble information – in this case, the definitions for myfield field.

When in your data, myfield is called for the static field, the dynamic definition is still in memory, causing it to try and access a non-existing structure – hence the error.

A short term solution would be to wrap myfield into a subform – this will cause a dynamic preamble to be created for it, overwriting the other template’s definition of myfield

Long term, the recommendation is
-when using multiple templates, avoid where possible having fields of the same name, across all templates
-do not mix static templates with dynamic templates – if such a situation arises, convert the static forms to dynamic, by grouping them in the appropriate subforms. Preferably, leave no field out of a subform