This content has been marked as final. Show 6 replies
try not declaring the fields as GLOBAL, so try to produce a transformation file which is made of ^fields commands instead of ^global.
In this case, while processing the field-nominated file, jfmerge will trigger a new subform each time it encounters a ^field referring a field of that form.
If you use the ^global, no event is generated (so no new form is shown) and data will be kept and shown every time you manually trigger a ^form command.
Using ^field commands, and supposing you have defined subforms in your document, you can also avoid to use the ^form statement in most of the cases: the ^field command will automatically show the form if a new istance of that form is required.
We don't use subforms so some of what you suggest isn't effective for us. Our forms are a duplication of the paper forms and are not dynamic. We design each form separately and our custom filler software (that builds the DAT file) uses a database with the required forms for each print job defined within it.<br /><br />Since we don't have subforms, our simple method of printing is to declare as GLOBAL all the unique fields used on all the forms to be printed followed by the ^form commands. It was a simple & straightforward method for us to do better than 500 print jobs over that past couple of years. In addition, our custom filler software can easily build the DAT files.<br /><br />Because I need to manually declare all the ^form statements my experience with using ^field is that the form must be declared followed by the appropriate field commands (repeat for all the forms).<br /><br />i <many hours later I continue typing this post><br /><br />Taking the original Transformation Definition File and customizing it for how things need to be when using ^field commands was a time consuming experience (and a learning one). It did the job as I needed but it is an experience I don't want to repeat. There has got to be a better way of building the TDF properly. I'm definately leaning towards a program to split the file into multiple files.<br /><br />Here is what I went through...<br /><br />I did all the editting using Notepad. I changed all ^global to ^field. Then I had to remove the #comment lines. Next was to find any references to fields that had to be global to the top and chang ^field to ^global. Then it was moving the fields around so they were underneath the appropriate ^form statement. Then, since one of the forms was multi-page I had to add the ^page command and sort the fields so they were under the correct page. That was followed by duplicating fields that are used on multiple forms or multiple pages. Then I discovered that the print agent won't do ^page unless "inline processing" is turned off (I did not want to specify the page name as it could change over time) - so I added "^inline off" in front of every ^page. Finally it was removing unecessary field references so the log file would be clean.<br /><br />For those that are interested, the following is an example of my final file. <br /><br />^global nameA<br />data<br />^global nameB<br />data<br />^form nameX<br />^field name1<br />data<br />^field name2<br />data<br />^form nameY<br />^field name1<br />data<br />^field name3<br />data<br />^inline off<br />^page<br />^field name4<br />data<br />^field name1<br />^inline off<br />^page<br />^field name5<br />data<br />^field name6<br />data
I think it depends also on how big are your forms.
If they take a whole page, some considerations could be done, otherwise it's different.
Mind that jfmerge parses the .DAT files and generates events to compile the final result page. ^global commands don't trigger any events, just store the value of the field in internal jfmerge dictionary, as you said.
But the ^form and ^subform commands will trigger events. Unfortunately, if I'm not wrong, global data will be put on page after having rendered ALL the page. So if you change their values in the meanwhile, only the last values are shown on every istance of you form.
Anyway I think you should describe also how your design is made, because the problem is not all up to the .DAT file.
Try also using something like this, just to verify what I'm saying (I'm not sure of it). I'm assuming both form1 and form2 fits on the same page:
Close, but no cigar - yet.
I took my original TDF (the one with ^global for all the fields followed by the ^form statements) and added the ^page command after the form that is fouling up. Page 1 of the form has the unique data for each record in my test file. Pages 2 & 3 of this form duplicate the data for the last record in my test file.
For simplicity, my test file has two records. My job has a 2 page form (no data added to the second page), a 1 page form, and 3 page form. What I get without the ^page command is the first two forms have unique data but both of the 3-page forms duplicate the data from the last record. With the ^page command after the 3-page form I get unique data on page 1 of that form but pages 2 & 3 duplicate the data from the last record.
I don't know what you mean by "describe ... how your design is made". These are simple single & multi-page forms - no subforms - no custom preamble - only the 2-page form has any !format scripting. The fields on all of the forms as "global". Each page is a "full" page with text & fields spread across the page top to bottom, left to right. As long as there is a single occurrence of data in the file it prints properly. Once there is more than one occurrence it fouls up.
I don't know what other suggestion to give you, except trying to substitute the ^page statement of the last mentioned TDF file with the ^eject statement.
This way it should print the page and the form should be populated again with the new data in the next step.
Good luck! ;)
No change. I still get unique data just on page 1 of the 3 page form and data from the last record on pages 2 & 3 for all instances.
Thanks for the help anyway.