Beiträge von woodpecker

    When trying to add a table with a width <> 100% using the WPTableDialog the table is always full width (though results are different when doing copy and paste to Word).
    When the table is supposed to be centered the position of the table actually seems to be calculated as though the table width really was smaller, but the table still remains wider, not minding the page margins.

    I find this issue in both my application and a (slightly) modified version of CrTableU:

    Code
    procedure TCrTableForm.Button3Click(Sender: TObject);
    begin
        WPTableDlg1.Execute;
    end;

    Are there any specific options I have to set before executing WPTableDlg1..?

    We are using WPTabDlg to edit the tabs.

    The first tab in the list of tabs is always shown as aligned left, although it should be aligned right (or aligned somehow else). All the remaining entries of this list do show the correct alignment.

    Can anyone confirm this issue / bug..?

    We're using WPTools 6.07

    We use the following routine to convert RTF to ANSI:

    Code
    function TWPTTextTransformer.RTF2Str(v: string): string;begin    wpt.TextLoadFormat := 'RTF';    wpt.AsString := v;    wpt.TextSaveFormat := 'ANSI';    result := wpt.AsString;end;

    (wpt is a TWPRichTextEdit)

    Now we have the issue that some customer came up with some text to convert that contains hidden parts, (using \v1). Whereas this hidden text is not shown on the TWPRichText it is part of the converted text.

    Is there a way to ignore hidden text during conversion?

    Here's the problematic RTF text:

    Code
    {\rtf1\ansi\deff0\uc1\ansicpg1252\deftab254{\fonttbl{\f0\fnil\fcharset1 Arial;}{\f1\fnil\fcharset1 Times New Roman;}{\f2\fnil\fcharset2 Wingdings;}}{\colortbl\red0\green0\blue0;\red255\green0\blue0;\red0\green128\blue0;\red0\green0\blue255;\red255\green255\blue0;\red255\green0\blue255;\red128\green0\blue128;\red128\green0\blue0;\red0\green255\blue0;\red0\green255\blue255;\red0\green128\blue128;\red0\green0\blue128;\red255\green255\blue255;\red192\green192\blue192;\red128\green128\blue128;\red0\green0\blue0;\red128\green128\blue0;}\wpprheadfoot1\paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440\headery254\footery254\pgbrdrhead\pgbrdrfoot\pgbrdropt32\endnhere\sectdefaultcl{\*\generator WPTools_6.030;}{\stylesheet
    {\s1\li0\fi0\ri0\sb0\sa0\ql\vertalt\fs24 Normal;}
    {\s2\li0\fi0\ri0\sb0\sa0\ql\vertalt\fs22 Default Paragraph Font;}
    {\s3\li0\fi0\ri0\sb0\sa0\ql\vertalt\fs22\cf3\ul\sbasedon2 Hyperlink;}
    {\s4\li0\fi0\ri0\sb0\sa0\ql\vertalt\fs22\cf6\ul FollowedHyperlink;}}
    {\pard\plain\plain\fs22\cf0\par'#$D#$A'\plain\fs22\cf0 Tel.: 01234-56789  Fax: 01234-56789  \line blablabla \line E-Mail: \ul IamNotHidden\f1\fs24\v1\ulnone IamHidden\f0\fs22\v0\ulnone   oder blabla
    \pard\plain\wpparid0\plain\cs3\fs22\ul\par
    }}

    I did some further investigating with this issue.

    It seems that the not sign arises in WPIOReadRTF in AppendChar, being a subroutine of TWPRTFReader.Parse

    Code
    if FStack.Destination = rdsFieldStringBuilder thenbegin   if FStringBuilder <> nil then begin      FStringBuilder.AppendChar(AnsiChar(aCh));   end;

    Casting aCh to AnsiChar (3864) results in Char(172) being ¬

    I get the correct output if I replace it with these lines:

    Code
    if FStack.Destination = rdsFieldStringBuilder then
    begin
       if FStringBuilder <> nil then begin
          if isUnicode then begin
              FStringBuilder.Append(Char(aCh));
          end else
              FStringBuilder.AppendChar(AnsiChar(aCH));
       end;

    I want to do a mailmerge using SuperMerge. The resulting text consists of three lines, the first and the last being empty.

    When I merge with RTF data the empty lines are being lost. The straight text version works, but of course lacks the formatting.

    Here's some code from my SuperMailMergeGetText which I used when trying to pinpoint the problem.

    Code
    if isRTF then begin
        Contents.Options := [mmDeleteThisField, mmMergeAsRTF];      // no empty lines in document
        Contents.StringValue := '{\rtf1 \par b\par }'
    else
        Contents.Options := [mmDeleteThisField];
        Contents.StringValue := #10#13 + 'b' + #10#13;               // empty lines in document
    end;

    I have got the feeling that I just lack a simple flag that needs to be set in order to get the empty lines with RTF as well...

    We are using TWPSuperMerge.

    wpmerge : TWPSuperMerge;
    wpt, wps : TWPRichTextEdit;


    wps has been loaded before via wps.LoadFromStream(source)

    Our current workaround is not to pass the original stream but to make a copy of it and to make sure that every line in this copy at least contains a blank (<space>) in it. Then the formatting is retained.