Page end problem with SuperMerge

Julian:

I haven't heard back from you on this topic, so I don't know if my e-mails are getting through. My problem sounds similar to the "Keep Next Problem" post, but V4.20 still has the problem. To re-iterate the problem, if I do a merge on a very simple document, whenever MergeParagraph hits a point where the distance between the bottom of the page and the last line of the paragraph is within a certain distance, it aborts the merge at the last completed page, rather than properly setting up to continue the paragraph at the next page. If I comment out the if statement around line 2270 in WPMerge that states:

if diff < FDestination.Header.FFontYPixelsPerInch div 10 then // 0.12 cm - one small line savety distance

then the merge completes, but I end up with one or more pages with a single line at the top. I'm attaching one of my e-mails that contains instructions on duplicating the problem.

I look forward to your response, and if anyone else has encountered this issue or resolved it, please let me know. Note that this used to work fine in V3.X of WPTools.

Sincerely,

Dr. Michael D. Foegelle

> > I can send you a project if you need it, but if you drop two
> > WPRichTexts, a WPSuperMerge, a Memo, and a button on a form
> > and put the following code in the click event of the button,
> > you'll get a demonstration of the problem. All this code
> > does is fills the control with 500 lines of text, then
> > changes the font size of the entire text and merges it for
> > different font sizes, checking to see if the merged document
> > has the same number of pages as the original. I get slightly
> > different results depending on whether I comment out the
> > rm1440 lines, but it still does it both ways. The mismatch
> > occurs when the line "if diff <
> > FDestination.Header.FFontYPixelsPerInch div 10 then // 0.12
> > cm - one small line savety distance" (around line 2270 in
> > WPMerge) of MergeParagraph is true. Anything you can do to
> > help would be appreciated.
> >
> > Sincerely,
> >
> > Dr. Michael D. Foegelle
> >
> >
> >
> > WPRichText1->Clear();
> >
> > AnsiString text;
> > for (int i = 0; i<500; i++)
> > text += (AnsiString) "This is test line #" +
> > (i+1) + "\r\n";
> >
> >
> > WPRichText1->Text = text;
> > text = "";
> >
> > for (int i = 5; i< 20; i++){
> > WPRichText1->SelectAll();
> > WPRichText1->Font->Size = i;
> >
> > //{ Empty the destination }
> > WPRichText2->Clear();
> > // { We need ScreenResMode 1440 ! }
> > // WPRichText1->ScreenResMode = rm1440;
> > // WPRichText2->ScreenResMode = rm1440;
> > //{ Copy the page and other settings to destination }
> > WPRichText2->FastCopyProperties(WPRichText1->Header);
> > //{ This starts the report creation }
> > WPSuperMerge1->Execute();
> > //{ Refresh the destination RTF text }
> > WPRichText2->Refresh();
> >
> > int p1 = WPRichText1->CountPages(), p2 =
> > WPRichText2->CountPages();
> > if (p1 != p2)
> > text += (AnsiString) "Mismatched page
> > count (" + p1 + " != " + p2 +
> > ") at font
> > size = " + i + ".\r\n";
> > }
> > Memo1->Text = text;
> >
> >
> > ------- Sample Output -------
> >
> > Mismatched page count (5 != 1) at font size = 5.
> > Mismatched page count (6 != 1) at font size = 6.
> > Mismatched page count (7 != 1) at font size = 7.
> > Mismatched page count (7 != 1) at font size = 8.
> > Mismatched page count (11 != 12) at font size = 11.
> > Mismatched page count (11 != 1) at font size = 12.
> > Mismatched page count (12 != 1) at font size = 13.
> > Mismatched page count (13 != 1) at font size = 14.
> > Mismatched page count (14 != 1) at font size = 16.
> > Mismatched page count (16 != 1) at font size = 17.

Thanks Julian.

I responded to your e-mail with more detail about what I'm actually doing, but I have an update on what I'm up against that maybe you can help with.

After spending the day chasing the problem around, I finally figured out that by fixing the page end issue (solution a), what happens without ignoring page height is that every page gets page breaks inserted. That's why I end up with one line on an otherwise blank page every so often. The line accidentally rolls over from the previous page due to the automatic formatting of the RTF editor. However, if I ignore page height to resolve that issue, then of course my tables don't insert properly (with new headers on each page) but instead just become one long table.

It appears that what I really need to do is default to having the IgnorePageHeight property set to true, so that when it merges the normal portion of the document, it just merges without reformatting, but when it encounters a group, switch to checking the page height. I tried using the two events for group start and end to hook in and apply the change, but that didn't do anything for me. I suspect that the event fires at too low of a level, where the IgnorePageHeight value has already been converted to the FCheckTheHeight parameter, so that changing it doesn't help. Either that, or the group start/end fires inside the page end check.

I'm pretty sure I can resolve the issue now that I understand exactly what's happening, but I'd rather solve it without extensive invasive changes to WPMerge. If you have any quick suggestions on where to hook in, they'd be appreciated. Thanks for your help.

Sincerely,

Dr. Michael D. Foegelle

Nevermind. On further inspection, that solution wouldn't work either. Some custom fields we have in the document that require tracking the page number as we merge don't work if IgnorePageHeight is set to true. Apparently the event we're using to track that and fill those fields isn't being called. We really need to resolve the dangling line problem, but from your e-mail reply it doesn't sound like that's going to be a quick or easy fix.

Sincerely,

Dr. Michael D. Foegelle

On further inspection, the problem appears to be more than just a dangling line. It appears that WPMerge can't split a paragraph across pages. Thus, if I create a two-page source document with two paragraphs, the first of which is longer than a page, then after the merge I end up with a three-page document that puts a forced page break after the first paragraph, and a soft page break in the middle of that paragraph. Thus, the rest of page two is blank after the first paragraph and the second paragraph (which fit on page two in the source) ends up on page three. Again, any suggestions would be appreciated.

Sincerely,

Dr. Michael D. Foegelle