Simply adding the banner form (or any form) in this manner will not automatically execute any rules or scripts associated with your fields. By the time you get to print, it is generally assumed that the forms are set and ready to go - rules already run, values already set, etc.

As the other reply suggested, it is possible to also define a banner script that can then be used to assign fields into your newly added form. This may be too much information, but if you want to assign data into the fields something derived from the existing fields in the document, you might be able to use a little known feature added a while back called "Print-time field" support.

GENERATING FIELD VALUES AT PRINT-TIME

You can now generate values for certain fields at print-time. This is similar to

page numbering fields that are calculated during the print process. These fields are not

normal entry or mapped fields but are instead placeholders into which the system inserts

a value during print processing.

The fields are designed using a naming convention associated with the INI builtin convention.

For example you could name your field:

~GVM gvmName

Where ~GVM is a registered built-in function (only) during Gendata and Genprint processing and

you follow this with the name of the GVM variable you wish to retrieve. During GenPrint (or single-step

GenData print), the field will query the built-in function to return the value from the GVM variable you

name and it will print that value.

Keep in mind...

• The name must begin with the tilde (~) character and name a legitimate built-in function recognized

in whatever process is doing the print. This is important, because GVM variables are not available

to certain processes. Other built-in functions may have process restrictions, so consider what

is applicable to your print situation.

• If a parameter is required, include a space between the function name and the

parameter.

• If you have duplicate fields that contain the #000 type ending on the name, that

portion of the name will be removed before execution. For instance, if you have one field name

~GVM gvmName and another field named ~GVM gvmName #002 these will actually retrieve the

same value because the #002 is dropped when searching for the GVM variable name.

Another example: If you want to print the current date in the field, you

could do that naming the field: ~DATE

And remember, ~DALRUN is a built-in function that will run a script. A script can be used to obtain

the value from any number of places within or outside of the current document - as long as it is

valid retrieval function for the process that initiates the print. You would name your field as:

~DALRUN MyScript

During print, the system will execute the named DAL script (MyScript in this example) which is expected to

return a value and becomes the output for this field.

There are a couple of caveats that you need to keep in mind. If your data is mapping into a text area or multi-line text field, the content will reformat, but it will not repaginate. This means that if you cause the text area to grow larger than its original size, it will NOT push other objects or cause the pages to span or contract. This is because print operations are already set in motion and it is not appropriate to re-flow document pages at that point. The other caveat is that if you name an incorrect built-in or the built-in actually fails to return a value, then the name of the field may actually print into your document. So for instance if you named it ~BLARG, this may actually print ~BLARG on your page because it is not a valid built-in function name at the time of print.