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.
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.
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.
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.
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?
I still cannot reproduce it- But there will be an update soon which has an improve "ShowMergeFields" mode and works much better with selecting + Drag&Drop of merge fields.
From my tests I cannot confirm that this issue is (still) there.
At least it looks like its something I'm doing, even if I can't find it. I'll just hold my breath until the new release so if you don't want a death on your hands get releasing <g>
After several hours of deleting components and events I've found the problem - ProtectedProperties ppIsMergedText. If this is true you get the behaviour I've been experiencing.
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.
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.
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
{$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.
