headers
Guy Algot | 15 May 02:04
Picon

Printing page 1 of X

I thought I would be able to do this easily but its not working out...

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.

My pseudo code...

For ($loop;1;1)

  main printing done here using PRINT FORM and PAGE BREAK(>)

   If ($loop=1)
    vL_TotalPages:=Printing page
    PAGE BREAK(*)
   Else
    PAGE BREAK
   End if

end for

Thanks.
(Continue reading)

Permalink | Reply |
headers
Jocelyn Climie | 15 May 07:47
Picon

RE: Printing page 1 of X

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
(Continue reading)

Permalink | Reply |
headers
Guy Algot | 16 May 03:59
Picon

Re: Printing page 1 of X

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
(Continue reading)

Permalink | Reply |
headers
Jocelyn Climie | 16 May 05:47
Picon

RE: Printing page 1 of X

I know the height of each section, because the way each 'section' form is designed all variables are printed
at fixed height (not sure if explaining it that well :-))

If the PRINT FORM is referring to area parameter of FORM HEADER 1, I know the height of the FORM AREA 1 is 9
pixels and that is what I add to my running total of the height of the page being printed

I hope this helps

-----Original Message-----
From: 4d_tech-bounces@...
[mailto:4d_tech-bounces@...] On Behalf Of Guy Algot
Sent: Friday, 16 May 2008 2:00 p.m.
To: 4D iNug Tech
Subject: Re: Printing page 1 of X

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:
(Continue reading)

Permalink | Reply |
headers
Arnaud de Montard | 16 May 10:21
Picon
Gravatar

Re: Printing page 1 of X


Le 16 mai 08 à 03:59, Guy Algot a écrit :

> 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?

You can't: only the form "knows" the objects (markers, fields and so  
on), and only its method form can read positions, resize them, and  
accept or not printing with CANCEL.

I use a wrapper of PRINT FORM, something like this:
   wrapPrintForm (->table;form{;printMarker{;maxHeight{;truncHeight) - 
 > height of printed section
when I pass $4 maxHeight =0, wrapPrintForm calculates but does not  
print. I use 4 process variables to send and receive params between  
wrapper and method form (pseudo params), as below.

   `method form
...
   `read pseudo params from process var:
$lMarker:=vl_printMarker  `$3 in wrapPrintForm
$lmaxHeight:=vl_maxHeight  `$4 in wrapPrintForm
   `read form objects
$lPosMarker:=Get print marker($lMarker)
$lPosPreviousMarker:=getPosPreviousMarker($lMarker)
$lBeforeResize:=$lPosMarker-$lPosPreviousMarker
(Continue reading)

Permalink | Reply |
headers
Guy Algot | 17 May 06:11
Picon

Re: Printing page 1 of X

I didn't think so.

I've been using Justin's PRINT FORM code from Summit. Good stuff...  
But I solved my original problem. Not sure why the difference but I  
was able to get it to work by executing the entire print method twice  
vs looping inside it twice. So this works;

vL_TotalPages:=0
vB_BreakNormal:=False

SET PRINT OPTION(Hide printing progress option ;1)
Quotes_PrintShippingForm

vB_BreakNormal:=True

SET PRINT OPTION(Hide printing progress option ;0)
Quotes_PrintShippingForm

Whereas before I was looping twice inside the  
Quotes_PrintShippingForm method. Thanks for the reply.

On May 16, 2008, at 2:21 AM, Arnaud de Montard wrote:

>
> Le 16 mai 08 à 03:59, Guy Algot a écrit :
>
>> 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. ;-)
>>
(Continue reading)

Permalink | Reply |

Gmane