Frame too big for Printer Page

Forums for specific tips, techniques and example code
ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Frame too big for Printer Page

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:49 pm

by Stephen Persson >> Thu, 4 Mar 2004 3:58:15 GMT

Hi,
I am wondering if anyone has any tips on what to do when a frame you have to print doesn't fit on a page, and you just want to print what fits, then carry the rest of the text over to the next page.
We use the printer.frameFits() method to check if the frame fits on the remaining space on the page, and at the moment just start an all new page if it doesn't fit. It's big text fields that we are printing so I'm trying to figure out a way that I can print part of that text on one page, and the rest on the next page.
Any ideas?!?

Thanks in advance
Stephen Persson

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Frame too big for Printer Page

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:49 pm

by cnwdad1 >> Thu, 4 Mar 2004 4:30:45 GMT

Stephen,

If you have BaseSchema, try the Printer::cnEcPrintToFitPage method - this will print the contents of the frame upto the end of the page, and then continue to print the rest on the next page. It's not super efficient, but it does the job.

If you don't have BaseSchema, let me know... I'm sure we can arrange a little code sharing :-)

regards,
darrell.

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Frame too big for Printer Page

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:49 pm

by Stephen Persson >> Thu, 4 Mar 2004 19:53:50 GMT

Sounds perfect, but no we don't have BaseSchema.
Good to hear you are a nice boy who shares his toys....... :-) stephen@tenderlink.com

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Frame too big for Printer Page

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:50 pm

by cnwdad1 >> Thu, 4 Mar 2004 20:05:25 GMT

Load the attached method into your schema (using the Advanced Schema Load options to set your target schema). The method scans the text to be printed token by token, which is fairly intensive, so only use the method conditionally when your frame won't fit the end of the page. You'll also need to strip carriage return and line feed characters first.
Attachments
3431_1.mth
(3.48 KiB) Downloaded 194 times
Last edited by ConvertFromOldNGs on Fri Aug 07, 2009 4:09 pm, edited 1 time in total.

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Frame too big for Printer Page

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:50 pm

by allistar >> Thu, 4 Mar 2004 7:42:22 GMT

You could always move all fields that don't fit onto a new frame, and print them. If you want to see large text fields chopped in half, then you could set the "top" property of the field to a negative value.

Regards,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Frame too big for Printer Page

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:50 pm

by Patwos >> Thu, 4 Mar 2004 8:54:34 GMT

Another approach is to print the report "a line at a time" by working out how much of the text will fit on 1 line using getTextExtent a character at a time, taking note of the last "white space" position to ensure words don't break in the middle of the word. You need to handle embedded CrLfs and situations where a single string with no "white space" is wider than the width you are allowing for a single line.

If you have multiple columns if does introduce another complication to the printing calculations as you now may have multiple columns for which you need to do the getTextExtent calculations to handle wrapping onto the next "line" of each respective control.

I tend to do the app.printer.print for each line rather than working out how many lines will fit onto the remaining space of the current page. It doesn't appear to be too inefficient doing the printing a line at a time even for reasonably large reports and makes the calculations easier, particularly when you have multiple columns that may potentially go over multiple rows. Having said that, once you have the code written it makes it much easier to produce multiple column reports where you are not sure how many lines each column will have and/or where you need to keep printing information in just some of the columns while other columns have finished printing their information several lines earlier.

eg: I ended up with several generic methods along the lines of the following and didn't have to concern myself anymore with handling columns of different lengths:

printMultiColumnLine1Up( column1Text : String );
printMultiColumnLine2Up( column1Text, column2Text : String ); printMultiColumnLine3Up( column1Text, column2Text, column3Text : String ); printMultiColumnLine4Up( column1Text, column2Text, column3Text, column4Text : String );

These methods all handled spanning onto the next page automatically, including repeating their subheadings with (ctnd) appended automatically etc. Makes adding new multi-column reports a breeze. :)

Hope that helps,
Pat.


Return to “Tips and Techniques”

Who is online

Users browsing this forum: No registered users and 16 guests