Don't want group totals to fall on page alone 2

[LTillner]

Sometimes, Group totals ONLY go to the second page of a report (when the # of avail lines matches the # of records in a group) I don't want this to happen. How can I force at least one record in the group to the second page with the totals????

Thanks for your help!

Lynette

 

[synapsevampire]

You can insert a page break before the group footer. This will place the entire group footer on the next page. If this isn't feasiblle, let me know, there are other ways.

Right click the group footer, select format section, select New Page Before.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[LTillner]

That's exactly what I'm trying to avoid.... I DON'T want the group footer on a page by itself. I want at least one detail record on the page with the group footer.

Thanks for any ideas.

Lynette

 

[synapsevampire]

I had read this:

"How can I force at least one record in the group to the second page with the totals????"

to mean that you wanted something in the group to print with some totals, not something in the detail to print with the group subtotals.

Not sure if this will work, but try adding a condition to the Detail page break before formula (or inner group) for next(<group field>) <> <group field> or onlastrecord.

This should force a new page at the change of a group or on the last page. The problem is it will always do so, meaning you'll get 1 detail line with the group footer data, even if the previous page only has one detail record.

Not very elegant nor appetizing, but it might do.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[Ngolem]

This is a tough problem and is related to the orphaned header problem.

Unfortunately Crystal doesn't know where it is on a page while it is printing out the report.

Placing a keep together on the the group doesn't help because you get ugly gaps in your report.

On occassion I have had to produce an &quot;as near as perfect as possible&quot; report with respect to page splitting. With no orphaned headers or footers.

The only way I could do this was to try to count the lines as they were printed (including header and footer lines). This is not easy since not all lines are of equal size and becomes impossible if the section is variable (ie. a subreport or &quot;Can Grow&quot; field affecting the boundries). I had refined my approach by actually measuring the amount of space each line of printed text took and added each line differently.

So...I installed these formulas on each line and then produced a display formula to see the values of the totals for each page (the totals were reset on each new page). I then, by trial and error, established values that I would trigger &quot;New Page Before&quot; actions for each header/detail line and footer.

Actually it worked quite well....but is it worth the effort of several hours of tinkering....it all depends on the client and how close to perfect they want that report to be.

So that is a thumbnail of the approach I took...If you want details let me know .... but this is not a quick fix... each report is different and you have to tinker with the values that you assign to each section that is printed until you get a reasonably consistant result. Jim Broadbent

 

[LTillner]

Jim,

What you did is EXACTLY what I need to do. These reports are our final product to our clients (both electronically and on paper) so it is very important to us that they are as perfect as possible!

Could you share more detail on the formula's you used? I have a single line detail section with boxes of a certain size and it doesn't grow, just the number of records per group changes, so that should help make it somewhat simpler for me, because I can control the size of the box around the data.

I can deal with the tinkering for the final report to be what we need. What is causing more of a pain, is making a zillion EXCEPTION reports and tinkering with them! Plus, I'd rather spend time getting the reports as perfect as possible once than always have to redo something for this exception or that!

Thanks!

Lynette

 

[synapsevampire]

Good idea, Jim.

I've had to take this approach too, but with a static environment. Not knowing the printer type, how the margins will work, fonts, etc....it can bite ya.

Try to standardize the height of your lines to be easy to work with, such as a standard size line, 1.5x that size, 2x that size, etc., this will make the task of determining page length easier.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[Ngolem]

Ok...here we go...this is not an exact science but stay with me and we shall see what we can do...the more complicated the report the more difficult it is to do.

FIRST

While printer fonts do vary they are close enough for this purpose.

From a printed page from the crystal report try to measure the height of each section printed...You can use grid snaps if you want but I like measuring in millimeter (I draw a temporary line top and bottom of each section for this measurement)

We shall use a simple example to illustrate the approach.

1. We shall assume no report header printed

2. we shall assume no sections suppressed

3. our report will consist of
- page header (30 mm )
- Group header (20 mm )
- details (10 mm)
- Group footer (15 mm)
- page footer (15mm) (you can forget about this except
for subtracting this from the
page bottom )

4. We shall assume that the Group header will not repeat on a new page (actually I usually like the hearder or a portion of it repeating so that the user doesn't have to flip back and forth to see what the data belongs to what group...but this will simplify it a bit)

5. We are going to use standard 8.5&quot;x11&quot; paper in portrait mode (this is 279 mm less 15mm for the page header is
279 - 15 = 264mm)

6. we shall assume that one or more complete groups can be printed on a single page.

7. Now we are going to create some addition formulas

@initialization
WhilePrintingRecords;
numbervar totalCount := 0;

***************************************************

@AddPageHeader (placed suppressed in the Page header)

WhilePrintingRecords;
numbervar totalCount ;

totalCount := totalCount + 30;

***************************************************

@AddGroupHeader (placed suppressed in the group header)

WhilePrintingRecords;
numbervar totalCount ;

totalCount := totalCount + 20;

***************************************************

@AddDetailLine (placed suppressed in the Detail Section)

WhilePrintingRecords;
numbervar totalCount ;

totalCount := totalCount + 10;

***************************************************

@AddGroupFooter (placed suppressed in the Group Footer)

WhilePrintingRecords;
numbervar totalCount ;

totalCount := totalCount + 15;

8. Now we create a total reset formula that is placed suppressed in the page footer

@ResetTotalCount

WhilePrintingRecords;
numbervar totalCount := 0 ;


9. NOW we are going to create a Totalcount display formula to see what is going on with the sums. this is just a diagnostic formula...since it is temporary and very small I highlight it with a yellow background so they are easy to find later

@Test_TotalCountDisplay

WhilePrintingRecords;
numbervar totalCount ;

totalCount ;

NOW SPRINKLE THIS FORMULA ON EACH LINE,HEADER AND FOOTER of the report and run the report as it is...just to see what is happening to the totals

MAKE SURE that you the numbers that you see look reasonable (for instance: the total as it approaches the bottom of the page before the page footer should be close to 264 by our example here)...also make sure the totals are resetting on a new page

10. NOW TRY TO SEE PATTERNS THAT YOU WANT TO SPLIT PAGES ON

for example

A) if a new Group header is going to occur and the count
is 264 - 30 = 234 (20 for the header + 10 for
one detail section = 30) then you can decide that you
would like this Group header to start on a new page.

Place this section in the Group section conditional formula for &quot;New Page Before&quot;

WhilePrintingRecords;
numbervar totalCount ;
totalCount >= 234;

B) if a detail section is going to be printed and the count
is 264 - 10 = 255 then you can decide to split to
a new page here with a similar formula in the detail
section.

WhilePrintingRecords; (in conditional &quot;New Page before&quot
numbervar totalCount ;
totalCount >= 255;

c) If the Group Footer is printed and the total is greater
than 264 - 30 = 234 (20 for the header + 10 for
one detail section = 30) then you can decide that you
would like this split to a new page AFTER printing so
you don't have an orphan header.

WhilePrintingRecords; (in conditional &quot;New Page before&quot
numbervar totalCount ;
totalCount >= 234;

11. NOW YOU RUN THE REPORT AGAIN and see if things split as you hope they will.....

NOW comes the tinkering part...you play with these numbers the size allotted to each section and try to get the best possible result...Sometimes the math doesn't seem right when it is done (conditional suppressed sections require special attention) but as long as you can get a reasonalbly consistant splitting total at the bottom of each page you should be all right.

Good Luck

BTW when things are perfect...remember to remove those yellow display fields
Jim Broadbent

 

[goranm]

Hi !

Maybe you already got a solution, but here you have an aproach that I have used sometimes and it works for me.

Start with making your group footer area little higher
and move the summary fields to the bottom of the section.

Then copy all the fields you have in the detail section and place them
in the top of the group footer, so you now have them in both sections.

It is only the last record for each group that will print in the group footer.

Now make a conditional formula (suppress option) in the detail section and
type the following formula:

{table.field} <> next({table.field}

The field that you compare, shall be the one that you group on.

Now if there is a page break just before the group footer you will have
one detail line together with your subtotal on the next page.

/Goran

 

[Ngolem]

Interesting approach

so the last detail is always printed in the group footer, no matter what...I like it...It doesn't help orphaned headers but it certainly would work on footers. It is also restricted to reports that don't use the footer for than just displaying a final total....but I see where it could be useful. Jim Broadbent

 

[synapsevampire]

Right, Jim, the same effect as I had suggested, though in a different way. It's the equivalent of placing a condition on the detail section to insert a new page if the next<group> <> <group>.

The real downside being that it will always create a new page with one detail line, even if the previous page only had one detail line...

Probably not optimal, but it satisfies the criteria.

Your idea will produce a more desirable effect, providing it holds up in the other environments (different fonts, printers, etc.), and Lynette is willing and able to code it out.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[LTillner]

well since the desired effect is to have ONE report not multiple versions for each -- I will go with Jim's suggestions. I suppose I could use multiple versions and have the Fox program that calls Crystal determine which report to use... but that's another approach altogether.

Thanks for your help guys!

Lynette

 

[synapsevampire]

Why would you have multiple versions in either Goran or my solution?

Perhaps you've some unspecified concerns, or you misunderstand the solutions offered.

Anyway, all you had asked for was:

&quot;How can I force at least one record in the group to the second page with the totals????&quot;

What you probably meant was that you were trying not to orphan the summary data at the group footer, so when this summary data kicks to the next page, you'd like at least one detail record to.

BTW, you could just use a counter at the detail level in Goran and my solution, and then only do the new page if the group changes AND the counter is X or more (X based on how much space your totals require). Basically the same effect as Jim's only very simple to implement, and it will never cause rewrites.

I offer a solution, if people are interested, or if they misunderstand, I'll pursue. You were interested in Jim's, so I just mentioned the pitfalls in approaching it that way, in part as a reminder to him, in part as a flag to you.

Anyway, all 3 solutions offered resolve this.

Good luck with the implementation, and try to learn your clients' environment and emulate it as you develop, have plenty of test data, you're in for some interesting experiences...

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[Ngolem]

SV - in your method you are always forcing the total to the second page with one detail line....with Goran....by attaching the last detail record to the footer and just suppressing the last detail line this will only be printed on the second page if it cannot be printed on the first page (assuming a &quot;keep together&quot; on the footer section).

His approach is interesting but does not solve all page splitting problem (such as orphaned headers). My approach addresses all of the problems and can be adapted to more complex reports Jim Broadbent

 

[synapsevampire]

I agree, Jim.

Your approach is more thorough, though any of the approaches satisfied the initial criteria, albeit in a funky way. But, if the splitting of pages only occurs if there are more than X detail records (perhaps page lines minus totals area number of lines, then it would create a page break in a reasonable way...probably...).

I controlled the print space as you suggest to do customized form printing several years ago in Crystal (uuugggghhhh), the problem was, when we switched laser printers, things were slightly off, and it caused a rewrite. if I had a non-static environment, where there are numerous printers, and numerous font possibilities (fonts being substituted because they don't have the same fonts), things might get dicey.

I'll try to avoid that one again.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[kenhamady]

I am not sure everyone caught what goranm was suggesting. I have used that technique with both the GH and the GF. You either suppress the first record of each group, or the last or both. Then you create a dummy detail either at the bottom of the GH, the top of the GF or both. It doesn't require any page breaks - because the section's 'keep together' does the work.

The only difference is that I usually use a running total to determine which records to suppress. RT=1 or RT= subtotal. Ken Hamady, On-site Custom Crystal Reports Training & Consulting
Public classes and individual training.
Guide to using Crystal in VB

http://www.kenhamady.com/

tek@kenhamady.com

 

[synapsevampire]

Ahhh, I get it, thanks Ken, and groanm.

I skimmed it thinking that a page break was also being used.

Sounds like the best solution.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com