Beiträge von foegelle

I'm running into an issue that if I have text being merged into a document that comes from a TMemo, such that it has CR/LF pairs in it, then the interpretation of the CR/LF causes problems when saved as text or RTF. WPTools displays it as expected, but if I pull the RTF into word, the separate CR/LF makes the merged text end up double spaced. In an exported text file, it just gives bad formatting and invalid characters. Comparing what the equivalent text gets saved as if pasted into a document, the line breaks are saved as /par, while the CR/LF pair ends up as a literal /'0D/line. Any suggestions?

Thanks,

Dr. Michael D. Foegelle

Ok, I've searched the web and help and can't find anything on this, so I don't know if it's possible. I need to be able to break a numbered list and insert an additional paragraph or graphic that's part of the same number, before continuing with the next number in the list. When I break the list, the remainder gets renumbered starting at 1 again. Is there anyway to specify the starting number for a numbered list, or otherwise resolve this issue?

Thanks,

Dr. Michael D. Foegelle

YAY! It's ALMOST perfect! The only problem I'm encountering now is that occasionally a soft page break occurs in the report causing the last line of a paragraph to wrap to the next page. In some respects it looks similar to what I started chasing originally. I suspect this is a minor tweak to resolve this one (I know you already have some sort of safety distance check in there). I almost need the ability to just turn off the soft page breaks once a report has been generated. Is that a possibility? Again, thanks for your help and any additional suggestions.

Sincerely,

Dr. Michael D. Foegelle

Julian, please refer to the thread on November 7th of "Page End Problem with Supermerge". The last post there was the exact same problem that started this thread. The problem is NOT with splitting tables, but with everything else.

Quoted from my last post that I never received a response to:
"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. "

This is the disastrous problem that makes my whole report generator useless. Even if I try to manually break each page in my report template and put them in separate bands, I still end up with extra pages and screwed up formatting. Needless to say, my bosses aren't happy, and I'm having to start looking for other solutions. Again, any help in resolving this problem is short order would be greatly appreciated.

I've been waiting on Julian to resolve this issue since last August. It's been holding up a release of our product because our report generator no longer works. I'm hoping he's made some progress, but I haven't heard anything from him since October/November timeframe. I even bought the full source to the RTF engine in the hopes that the extra cash would be incentive for him to fix it. Unfortunately, although I have a general idea of where the problem is (and don't think it's in the engine anyway), the code isn't well documented, so I don't quite know what everything is doing. If you discover a solution, I'd really welcome the info. This bug didn't exist in V3.X.

(Note that it IS possible to completely turn off the report merge page breaks, which eliminates the unwanted breaks, but results in tables spanning pages without headers, etc. It also breaks our page counting during a merge that's used to put special labels in, etc. As far as the merger is concerned, it's all just one big page.)

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

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

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

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.