PDF printing with formm command

[Bruce Easton]

Yes, Bill - I will try to submit that, but I just discovered possibly 
something else I could have done. If I copy the supplied "fpml3" print 
code table to a new one called "fpml3noinit" and I blank out the 
"Initialization print code number" (on the options screen of the print 
code table), and set my PFPRTC to this new print code table, then now 
this suddenly works as desired!

And since I'm doing this form "set" assembly from processing, I can 
change the print code table as needed (although I need to introduce that 
as a new "control" field that the end-user needs to understand).


On 6/13/18 4:43 PM, Bill Randall wrote:
>
> That sounds like a bug that should be reported, Bruce.
>
> Bill
>
> On 6/13/2018 4:31 PM, Bruce Easton via Filepro-list wrote:
>> I've been having some great results giving one client, that has 
>> limited filepro processing capability, the ability to build their own 
>> sets of forms that output from their web-based application as PDF, 
>> sequenced and categorized as the client dictates.  (Using the new 5.8 
>> feature to create PDFs directly from filepro.)
>>
>> I ran into an issue, though, using the formm command where I'm not 
>> sure if it should be considered a bug.  I have, for years, used the 
>> formm command to piece together pieces of forms where one format 
>> might be only a line or two high, for various purposes where one 
>> might be the output from a series of child file records.  This has 
>> for me been historically useful (over just using rreport) in cases 
>> where you may want to mix and match header/detail forms and where the 
>> operator can choose between the pieces of output that they would like 
>> ultimately as one document.
>>
>> Normally, filepro doesn't paginate with each formm command, and that 
>> has made it useful for, as mentioned above, outputting detail lines 
>> within a lookup loop (from rclerk).  What I'm finding with the new 
>> PDF printing within filepro is that the formm command does seem to 
>> always paginate at the start of the format.  I've tried this with and 
>> without different <page...> markup height settings - which are 
>> obeyed, but I still just get a new page when using formm, even if the 
>> resulting PDF page is only a few lines tall.
>>
>> To work around this, I'm  calling rreport to do the job, but rather 
>> than running out of the detail file, I am calling rreport with a 
>> specific record (-sr) and then inside the output processing, I am 
>> using a loop to output the detail using the "print" command -this 
>> works nicely and quickly, and I didn't have to modify very much of my 
>> original code that was meant for rclerk.
>>
>> The formm command does allow output from multiple output formats to 
>> be combined into one PDF (terminating with "form" command), but it 
>> seems that having formm always paginate in this scenario is not 
>> historically consistent.
>>
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>