16 May 03:59
Re: Printing page 1 of X
From: Guy Algot <guy@...>
Subject: Re: Printing page 1 of X
Newsgroups: gmane.comp.lang.inug-4d.tech
Date: 2008-05-16 01:59:34 GMT
Subject: Re: Printing page 1 of X
Newsgroups: gmane.comp.lang.inug-4d.tech
Date: 2008-05-16 01:59:34 GMT
Thanks for the reply. My form is similar. I am using multiple calls to PRINT FORM to print the various sections. I have used PRINT BREAK(*) before without problems when printing a couple of sections but I suspect that the calls to PRINT BREAK(>) have something to do with it. I was hoping to not go thru what you have done to get it to work. Print the form, get the #, cancel it, then print for real. Never as easy as it seems.So if you suppress the PRINT FORM, how are you getting the height of each section? On May 14, 2008, at 11:47 PM, Jocelyn Climie wrote: > I had a similar request from a client to have this information on > the bottom of schedule attached to an invoice. > > It is important to note the form I was printing was broken down > into different sections (e.g. header, subheading, lines, sub total > etc) using markers and I was using the PRINT FORM command with the > area parameter. > > So for each schedule I went through the print code twice. First > time to work out total pages, second time to do actual printing. > > First time through the loop I suppressed the page breaks & print > form commands. I worked out total pixels per page using GET > PRINTABLE AREA. Then instead of doing PRINT FORM command I kept a > running page height total of the height of the form that would have > been printed (e.g. instead of executing print form to print line I > added 13 pixels to running page height total). When the running > page height total exceeded the total pixels for page, I incremented > a running total of the page numbers & reset the running page height > total to zero & moved on to the next page etc > > I hope this makes sense! > > Regards > > Jocelyn > >> Client has asked for an addition (to an existing report that uses >> PRINT FORM) of a 'Page 1 of X' label in the footer where X is the >> total number of pages in the print job. Since the print out is an >> invoice style job, the number of pages is based on the number of >> records used. However, some of the lines can grow to accommodate text >> as well. > >> Only way I can think to do this is to print the entire job, grab the >> total number of pages, cancel it, and then reprint it. However, if I >> print the entire job, then call PRINT BREAK(*) instead of PRINT BREAK >> then redo it again normally, nothing happens the second time. Later, Guy ********************************************************************** The 4D v11 SQL Roadshow - coming to a city near you! http://www.4D.com/roadshow/index.html 4th Dimension Internet Users Group (4D iNUG) FAQ: http://www.4d.com/support/faqnug.html Archive: http://dir.gmane.org/gmane.comp.lang.inug-4d.tech Unsub: mailto:4D_Tech-Unsubscribe@... Post: mailto:4d_tech@... Options: https://lists.4d.com/mailman/listinfo/4d_tech **********************************************************************
So if you suppress the PRINT FORM, how are you getting the height of
each section?
On May 14, 2008, at 11:47 PM, Jocelyn Climie wrote:
> I had a similar request from a client to have this information on
> the bottom of schedule attached to an invoice.
>
> It is important to note the form I was printing was broken down
> into different sections (e.g. header, subheading, lines, sub total
> etc) using markers and I was using the PRINT FORM command with the
> area parameter.
>
> So for each schedule I went through the print code twice. First
> time to work out total pages, second time to do actual printing.
>
> First time through the loop I suppressed the page breaks & print
> form commands. I worked out total pixels per page using GET
> PRINTABLE AREA. Then instead of doing PRINT FORM command I kept a
> running page height total of the height of the form that would have
> been printed (e.g. instead of executing print form to print line I
> added 13 pixels to running page height total). When the running
> page height total exceeded the total pixels for page, I incremented
> a running total of the page numbers & reset the running page height
> total to zero & moved on to the next page etc
>
> I hope this makes sense!
>
> Regards
>
> Jocelyn
>
>> Client has asked for an addition (to an existing report that uses
>> PRINT FORM) of a 'Page 1 of X' label in the footer where X is the
>> total number of pages in the print job. Since the print out is an
>> invoice style job, the number of pages is based on the number of
>> records used. However, some of the lines can grow to accommodate text
>> as well.
>
>> Only way I can think to do this is to print the entire job, grab the
>> total number of pages, cancel it, and then reprint it. However, if I
>> print the entire job, then call PRINT BREAK(*) instead of PRINT BREAK
>> then redo it again normally, nothing happens the second time.
Later,
Guy
**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
RSS Feed