Problem with 2 consecutive Insertpoints

  • I've recently updated my WPTools 4 to version 4.25, and currently I'm detecting problems with mailmerge.
    I've found that the problem only appears when there are 2 consecutive insertpoints in the text. With the previous version I was using (4.11c) I never had this problem.

    Example:
    If I have the following insertpoints, one next to the other (%[VAL1]%[VAL2]) and CPPosition points to the first percent sign, this method call: WPRichText1.ReadFieldAtCP(FieldName, FieldText)
    Results in
    FieldName -> %[VAL1]
    FieldText -> %[VAL1]%[VAL2]

    Besides that, in the screen, only the first % is highlighted as an insertpoint delimiter.

    Has anybody seen this? Perhaps it is a problem of how I create the insertpoints?

    Thanks for your attention.

  • Hello,

    As I posted it here yesterday, I have the same kind of problem. After more investigations, it seems that the file does not save correctly (using saveToFile()).

    When I open my RTF file with notepad, at the end of the file instead of having what I guess should be :

    Code
    {\field{\*\fldinst{MERGEFIELD Field0 }}<\plain\f0\fs22\cf0 Text0}\plain\f0\fs22\cf0 {\field{\*\fldinst{MERGEFIELD Field1 }}<\plain\f0\fs22\cf0 Text1}}}


    I have :

    Code
    {\field{\*\fldinst{MERGEFIELD Field0 }}<\plain\f0\fs22\cf0 Text0<\plain\f0\fs22\cf0 Text1}}}


    The beginning is similar but there is a missing part at the end.

    I've checked all properties of the TWPRichText component but none seems to impact on the problem.

    Any help would really be appreciated.

    Jeffres

    PS : Here is a copy of my message on newswhat forum, sorry for the length of my post.

    I am facing a problem with WPTools 4.x (not sure about the exact version,
    could anyone tell me how to get it ?) in C++ Builder 5. I've found no
    other mention of this kind of issue over the Internet, so I hope someone
    could help me here.

    What I do is quite simple.

    I have a form with a TWPRichText and 3 buttons : "Insert", "Merge" and "Load".

    The "Insert" button adds a mail-merge field with the text "Texti" and the
    field name "Fieldi" (in which i is a number incremented each time one
    click the button).

    The "Merge" button first saves the TWPRichText content in a file and then
    merges the text.

    The "Load" button simply loads again the file.

    ---------------------------------------------------------

    Here are two examples, the first that works right, and the second that
    demonstrates the problem :

    1) I click on "Insert" 3 times, pressing the enter key between each click
    to go on a new line, as to obtain the following text :

    Code
    <Text0   <Text1   <Text2

    2) Then I click the "Merge" button, what results in :

    Code
    <Field0   <Field1   <Field2


    3) Then I click the "Load" button which gives me again :

    Code
    <Text0   <Text1   <Text2


    And so on, that works. But let's see the other case :

    1) I use the "Insert" button and the Enter key to obtain the following text :

    Code
    <Text0<Text1   <Text2


    2) Then here is what I obtain when merging, what seems correct :

    Code
    <Field0<Field1   <Field2


    3) But then when I reload the file, I again have the text as in 1), except
    that the '<' character before "Field1" isn't red (as all insert points
    generally are) but black.
    And if i merge again, I get :

    Code
    <Field0   <Field2


    "<Field1" has disappeared !!!

    And that happens as soon as 2 mail-merge fields are put side by side, what
    means that if I had put a space or any other character between "<Text0"
    and "<Text1", then everything would have gone all right.

    Has anyone met this problem or have a solution ? Is it a bug from WPTools ?

    Thanks for your answers.

    Jeffres

    ---------------------------------------------------------

    Here is the code executed when I click the "Insert" button :

    Code
    static int i;   WPRichText1->InputField(   '<',                              PERString( "Text" ) + IntToStr( i ),                              PERString( "Field" ) + IntToStr( i ) );   i++;

    Here is the code executed when I click the "Merge" button :

    Code
    WPRichText1->InsertPointAttr->Hidden = false;   WPRichText1->SaveToFile( "test_edition.rtf" );   WPRichText1->MergeText();


    Here is the code executed when I click the "Load" button :

    Code
    WPRichText1->LoadFromFileWithClear("test_edition.rtf");


    And here is the MailMergeGetText function of my TWPRichText :

    Code
    void __fastcall TfrmDossierDevis::WPRichText1MailMergeGetText(
             TObject *Sender, const AnsiString inspname,
             TWPMMInsertTextContents *Contents)
       {
          Contents->StringValue = inspname;
       }
    • Offizieller Beitrag

    Hi,

    I would recommend to use the edit fields. They have start/end markers and can so avoid that the merged text and the mailmerge fields get mixed.

    InputEditField creates such a marker.

    Internally they work alike.

    WPTools 5 uses modified fileds (all have start/end tags) and they use a Word compatible syntax in RTF. I strongle recommend to upgrade.

    Julian Ziersch

  • Hi,

    Thanks for your answer.

    I just tried to use InputEditField but it doesn't seem to work better (it is even worse) : after a merge the end tag isn't recognized anymore and is considered as a normal character.

    Perhaps there is something I do wrong.

  • I'm having the same problem with v4.25. I use InputEditField to create the edit fields, then when I save the file and reload it, it is messed up. I didn't have this problem with v4.

    As an example, if I create the following as a document:


    <<Edit1>> <<Edit2>>  <<Edit3>>  <<Edit4>>

    <<Edit5>>
    <<Edit6>>

    Then if I save the document and open it again, I see:

    <<Edit1>> <<Edit2>> <<Edit3>> <<Edit4>>

    <<Edit5
    <<Edit6

    Then of course, merging will not work.
    I plan to upgrade to V5, but it is going to take some time because of the large amount of development that has been done with v4, so in the meantime, is there a fix for this? I don't think I'm doing anything wrong, or am I?

    Thanks!

  • Sorry, I made a typo on the example above, the end markers are actually missing from Edit4, (not just there, but black.) The RTF code in the file reflects this also, so it appears to be a problem when saving.

    Also, it appears after further examination that after saving the document, the end markers are missing from every edit field that is the last in each line. For every other in the line, the end markers are now black instead of red & will not merge correctly.

    This happens whether I use SaveToFile(), or click the Save Icon in the toolbar.

    Thanks.

  • I am experiencing the exact same problem. Is there a fix to this, a newer version for 4 than 4.25? I have had to roll back to the previous version. Like others, the plan is to move to 5, but there is a large amount of code that has to be handled. Any help would be appreciated.

  • Same problem as outlined above, and like the previous poster, moving to 5 is not an immediate option. Nor is moving away from mergefields.

    Any work-arounds or changes to the source that we can make to avoid this problem?

    • Offizieller Beitrag

    Hi,

    I am sorry - You pick up a post from 2006. WPTools 4.25 is now 6 years old and the latest WPTools is V6. I don't even know which WPTools build You are using and what problem there seems to exist.

    When you save your fields wptools 4 should be able to load them again. The compatibility to other RTF tools has been improved for V5 and V6 - esspecially the field support has been re-thought.

    Julian

    • Offizieller Beitrag

    Hi,

    When You open WPWrtRTF.PAS You will find around line 2748 this code

    Code
    if (afsIsInsertPoint in save_pa^.Style) and not FIsLastChar and not bLooped then        begin          bLooped := TRUE;          continue;        end;


    You can replace this with

    Code
    if (afsIsInsertPoint in save_pa^.Style) and not FIsLastChar and not bLooped then
            begin
             // bLooped := TRUE;  - commented out Dez 2010
              continue;
            end;


    It should work now.

    The detection of loops was intended to fix wrong templates.

    Julian