TRichView.com

Hi Sergey,

I've upgraded my IDE to Addict4 (which I was going to do anyway) and also installed the latest version of the Parser from your site. However, I'm still getting the same problem.

My current version of the program which was compiled with RichView10, Addict 3.4.4 and a quite-old version of the parser does not show the problem.

Here is some more information:

Tracing the code from the point in my previous message on this topic:

procedure TRichViewParser3.ReplaceWord( Replacement:String; State:LongInt );

and it appears to be proceeding correctly until it gets to

FEdit.SetCurrentItemText(s);

At this point the string s contains

'V'#0'e'#0'r'#0'm'#0'o'#0'n'#0't'#0

Tracing 'into' the above statement goes into this procedure in RVEdit:

procedure TCustomRichViewEdit.SetCurrentItemText(const s: String);
begin
{$IFDEF RVUNICODESTR}
SetCurrentItemTextW(s);
{$ELSE}
SetCurrentItemTextA(s);
{$ENDIF}
end;

and steps down to the SECOND item. I'm wondering if it shouldn't be the first instead since the string has all those #0 characters in it?? In any case, tracing further it goes here:

procedure TCustomRichViewEdit.SetCurrentItemTextA(const s: TRVAnsiString);
begin
{$IFNDEF RVDONOTUSEINPLACE}
if (InplaceEditor<>nil) and (InplaceEditor is TCustomRichViewEdit) then begin
TCustomRichViewEdit(InplaceEditor).SetCurrentItemTextA(s);
exit;
end;
{$ENDIF}
TRVEditRVData(RVData).PrepareForEdit;
SetItemTextEdA(CurItemNo, s);
end;

Then into SetItemTextEdA(CurItemNo, s);

at which point it errors on the GetCurrentItemNumber step with the "Invalid Caret Position" error.

Since all of the above operations are inside the RichView code, it seems like the problem must be with TRichView?

Please let me know if I can be of further help in debugging this issue. As I've said - I can't release my program with such a glaring bug in it...

Thanks in advance for your help with this issue.

Dick

Are you sure you installed the latest version of the parser? In the latest version of parser (2.1), TRichViewParser3.ReplaceWord does not call SetCurrentItemText, it calls SetCurrentItemTextR.

Well, yes, I INSTALLED it... but the old parser which was located in the Actions directory was still there... And the path to the Actions directory came before the path for the location of the new parser. Soooo... I was actually still USING the old parser, though I didn't know it.

All is working correctly now. Thanks for pointing me in the right direction

Dick