3 Replies Latest reply on Sep 9, 2013 10:18 PM by DaveS

    Mapping data on a banner page


      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 Factory:

      Documaker 12.1 Enterprise Edition

      Microsoft Windows x64 (64-bit)(2008 R2)



      Oracle Database - Enterprise Edition -

      IBM AIX on POWER Systems (64-bit)(6.1)





        • 1. Re: Mapping data on a banner page

          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.

          • 2. Re: Mapping data on a banner page
            Mr Peabody-Oracle

            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.



            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


            • 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.

            • 3. Re: Mapping data on a banner page

              Thanks User_9976634.


              I used the ~DALRUN example you provided and it works great.


              Another success for the OTN Message board.