This discussion is archived
3 Replies Latest reply: Sep 9, 2013 3:18 PM by DaveS RSS

Mapping data on a banner page

DaveS Newbie
Currently Being Moderated

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:

;BANNER;BANNER;SLIP_PRODUCERCONFIRM;

 

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)

 

Database:

Oracle Database - Enterprise Edition - 11.2.0.3

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

 

 

Thanks!

Dave

  • 1. Re: Mapping data on a banner page
    Tony Newbie
    Currently Being Moderated

    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
    user9976634 Journeyer
    Currently Being Moderated

    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.

  • 3. Re: Mapping data on a banner page
    DaveS Newbie
    Currently Being Moderated

    Thanks User_9976634.

     

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

     

    Another success for the OTN Message board.

     

    Dave

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points