Looking to add some very simple dynamic data to my banner pages, but for some reason I can't figure it out.
I am able to generate a static form successfully using the following BatchBannerBeginForm:
Now I edit the section to add a field with a simple DAL rule: RETURN("Test");.
For some reason it won't write the word "Test".
Eventually, I want to map in Batch ID, transaction IDs, etc. but for now I just want I to execute a simple DAL script.
A few stats about my system:
Documaker 12.1 Enterprise Edition
Microsoft Windows x64 (64-bit)(2008 R2)
Oracle Database - Enterprise Edition - 22.214.171.124
IBM AIX on POWER Systems (64-bit)(6.1)
Return is just going to hand a value back to whatever is calling the script, which isn't going to cut it in this case. If you want a field to populate with a value on a banner form, try the following:
- Add a field to a section on your banner form (we'll call the field POLNUM)
- Update your INI to use a BatchBannerBeginScript (right below your BatchBannerBeginForm), we'll call the script BANNER_SCRIPT
- Create a DAL called BANNER_SCRIPT that includes the following line:
POLNUM = "Test"
Run RP, and you should see Test wherever you put that field.
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:
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
• 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:
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.