Behaviour change V5 to V6 (InputMergeField)

1. offizieller Beitrag

    Julian

    My memory may be wrong but I think the behaviour has changed between V5 and V6. I insert a user selected merge field into a document using

    Document.InputMergeField('fld_' + IntToStr(TMenuItem(Sender).Tag), SubFld(TMenuItem(Sender).name, '_', 3) + ': ' + TMenuItem(Sender).Caption);

    With the cursor at the end of the merge field if I then press the enter key the cursor moves down a line, but I HAVE to enter a keyboard character before pressing enter again will work.

    Obviously I need to do something differently but what?

    Think in terms of setting up a template for a form email. Insert the merge field for the contact name, press enter a couple of times and start typing the text for the email. Only now I can't because the cursor won't move down.

    Julian

    A bit more info - its not just newly inserted merge fields. It also applies to existing ones in a document. Position the cursor after the merge field markers and second presses of the enter button are ignored until a normal key is pressed.

    Julian

    This is where I'm inserting a mailmerge field programmatically, the markers are visible since I'm setting a template up rather than merging data in. I can see where the cursor is (I think) and if I (for example) enter a space then everythings OK but if I just press CR it isn't accepted.

    Julian

    We seem to be having a bit of a communication breakdown. I can see the cursor but it just sits there and doesn't move until I type a character in.

    Try this

    Drop a TWPRichText (Document) on a form, add a button and in its OnClick event put the following

    Code
    Document.InputMergeField('fld' + IntToStr(47), 'aaaa');

    run it. Click the button, click into the document after the merge field and just press CR. The cursor will move down 1 line (ie the line after the merge field) and "stick" until an alphameric key is pressed a couple of times. The first press isn't displayed.

    Roy[/code]

    Roy,

    I don't really have much to add that will help but at least you won't be alone here. I am using a different environment (Delphi 6 on Windows XP) but I am performing identical actions to yours. I programmatically add merge fields both by clicks and drag-n-drop.

    Following your steps, I click to add my merge field and position my cursor just after the tag marker and press CR. For me, the CR character is accepted correctly. I tested positioning the cursor BEFORE the merge field, AFTER the merge tag, and INSIDE the merge tags and it worked correctly for me each time. Sorry. Perhaps you have an event that is absorbing the CR key?

    Regards,

    Rich Ackerson

    • Offizieller Beitrag

    Hi,

    Yes, I see what you mean. You should really display the merge objects for debugging.

    You then can see, that if the cursor is INSIDE the field, before the end tag, it is not possible to enter text. The first character You type skips this object and you can type agaian, AFTER the field.

    InputMergeField should place the cursor AFTER the field, I tested in V6.03 that it really does.

    For Yor templates consider to use the ShowMergeFields mode - it is pretty powerful, the merge fields casn be easily selected and moved.

    Julian

    Julian

    Good to see you can now duplicate the effect.

    If by "For Yor templates consider to use the ShowMergeFields mode" you mean setting ShowMergeFieldNames to true I've just tried that, and I may go with it as an option (means changing all my names but WTF).

    However, it makes no difference to what I think is a problem. The cursor IS flashing outside the merge field BUT if the first key you press is CR there is a problem. Anything else (a..z etc, even #9) is fine but a CR screws it.

    Hi Roy.

    I experienced the exact same problem you are having after having updated WpTools 5 to WpTools 6.
    I managed to track down the problem to the following code inside unit WPRTEPaint.pas

    Code
    {$IFDEF WP6} 
              if aCursor.active_posinpar = 0 then
              begin
                apar := aCursor.active_paragraph;
                while (apar <> nil) and (apar.prev <> nil) and (apar.CharCount = 0) do apar := apar.prev;
                protmode := IsProtected(apar, apar.CharCount - 1);
              end else
{$ENDIF}

    The same code appears on 2 different places inside the method:
    function TWPRTFEnginePaint.InputString(const Text: string;
    HandlePaint: Boolean = FALSE; CodePage: Integer = 0): Boolean;

    If you comment this code i believe all your problems will be gone, at least thats what it did for me.

    I also do not understand the logic behind it. If you are at the first position in a empty paragraph the paragraph protection will be decided by the protection on a previous paragraph. It doesn't seem like something most people would consider helpfull.

    • Offizieller Beitrag

    The problem was caused by setting

    Inserting := false

    in unit WPCtrMemo, TWPCustomRtfEdit.InputCode.
    That has been change in the meantime.

    Now it reads

    That change should be in the latest WPTools 6.

    Julian