Is this a tStrings.Add (or Append) bug?
Ted Michon
tMemo that I'm using as a quickly scrolling terminal display.
As packets of characters arrive in arbitrary little bursts, I append
them to the tMemo.lines using Append. The characters use CR+LF to
separate lines.
If the packets of characters arrives such that last character in the
packet is a CR (the LF becomes the first characters in the next
packets), the problem occurs. The combined CRLF is replaced by a single
square box character and the packets are placed in the same line.
I can work around it in my code by checking to see if a packets ends
with CR, in which case I delete the CR. If a packet starts with a LF, I
prepend a CR.
But it seems to me this is a bug in tMemo.lines, or am I
misunderstanding something?
-Ted
Aaron Rhodes (Borland)
It looks like it is working as designed. the CR charachter is valid as the
little box to a string field and removing that as an invalid charachter
would cause other obvious problems. I believe though, what you can do since
a memo.items.add will add the CRLF for you, is to strip both of those
characters from your lines before executing it.
R/S Aaron Rhodes
Delphi Technical Support
Ted Michon
Thanks for responding.
I'm a little confused, probably because of some typos in the second sentence:
"the CR charachter is valid as the little box to a string field and removing
that as an invalid charachter would cause other obvious problems."
I don't agree with the next sentence. If I delete both the CR and the LF before
calling Add (or Append), all the text would go on the same line in the string
field, not split across two lines as desired.
I note from further experimenting that I can also solve the problem by deleting
any LF that occurs at the start of a string before calling Add (or Append).
-Ted
Mike Williams
before
> calling Add (or Append), all the text would go on the same line in the
string
> field, not split across two lines as desired.
>
> I note from further experimenting that I can also solve the problem by
deleting
> any LF that occurs at the start of a string before calling Add (or
Append).
Add and Append both are for adding a line at a time. I suppose that if
there's a CR or LF in the string that it makes sense that two lines would be
added. However, I would assume that you would want to preserve the existing
line breaks in the incoming data. If the total amount of incoming data is
fairly small, you could just do the following without regard to the line
breaks:
Memo1.Text := Memo1.Text + IncomingString;
If there is a lot of incoming data, I would buffer it internally and add it
a line at a time:
Buffer := Buffer + IncomingString;
p := pos(#13#10, Buffer);
while p > 0 do begin
Memo1.Lines.Append(copy(Buffer, 1, p-1));
Delete(Buffer, 1, p+1);
p := pos(#13#10, Buffer);
end;
-Mike
Philippe Ranger
I've been tracking down a pesky problem with a corrupted character in a
tMemo that I'm using as a quickly scrolling terminal display.
As packets of characters arrive in arbitrary little bursts, I append
them to the tMemo.lines using Append. The characters use CR+LF to
separate lines.
If the packets of characters arrives such that last character in the
packet is a CR (the LF becomes the first characters in the next
packets), the problem occurs. The combined CRLF is replaced by a single
square box character and the packets are placed in the same line.
>>
Append merely calls Add. Add calls Insert. This is TmemoStrings.insert in
stdCtrls. This prepends a CR-LF if we're at memo end, else it appends one.
Then the package is left to the good care of the Windows editbox control.
This is where your "problem" lies. I think linewrap is making your two lines
join, and that the starting LF in the second one, seen by the control as
CR-LF-LF, is not treated as a line end, but an extra, undisplayable char --
hence the box.
The workaround is to check your string before calling Append. If the string
ends in #13, add a #10. If it starts with a #10, delete it.
PhR
Ted Michon
Your work around is symmetrical to the one I mentioned (mine: if the string ends
in #13, delete it, if it starts with #10 prepend a #13). Both work. Turns out it
also works simply to delete #10s at the start of strings.
(Actually, I only use Add/Append if the tMemo is empty. Otherwise, I add text by
concatenating my string with the string at the end of the stringlist. I actually
don't observe the problem from Add/Append (they only get called once)).
-Ted
Ted Michon
I should point out that I only use Add/Append if the tMemo is empty. Otherwise,
I "add" text by concatenating my string with last string in the stringlist. (I
don't observe the problem from Add/Append (probably because they only get called
once)).
Preserving the existing line breaks, as you pointed out, my the whole problem:
if the line break happens to split between two sequential incoming strings, the
line break is corrupted in favor of a square box followed by the second string
on the same line.
Your solution, if I understand it, solves my problem except that current text
(the most recent incoming characters not ending in CRLF don't get displayed
(which would be annoying behavior for a terminal).
-Ted
Rudy Velthuis
>(Actually, I only use Add/Append if the tMemo is empty. Otherwise, I add text by
>concatenating my string with the string at the end of the stringlist. I actually
>don't observe the problem from Add/Append (they only get called once)).
You're confusing a string list with the Strings a memo has. TStrings is
an abstract class, that must be overridden. For a memo, the class is
TMemoStrings, which is not published in the intrface section of the unit,
but dfind and implemented in the implementation section.
It is not a string list, it's a wrapper for the internals of the Windows
multiline edit box. So the problems stem from Windows.
I would just place a CR at the end of a packet on hold. So if the last
char is CR, I would store it in a single Char buffer. If a packet starts
with LF and there is a CR in the buffer, append both AND empty the
buffer again. If the buffer is empty (#0), don't use the LF.
I would not use Add/Append once and then add to the last line. I would
always add to Memo.Text (Memo.Text := Memo.Text + CharsReceived).
--
Rudy Velthuis
Ted Michon
Concatenating to tMemo.Text, as you suggested, solves my problem.
(I went back and forth with someone from Borland via email, and we agreed on some
sample code that shows that concatentating with the last line in tMemo.lines directly
did, in fact, fail under the condiditons I described).
Thanks.
-Ted
Arthur Hoornweg
The easiest way is to internally buffer all incoming data,
and to only add it to the memo after a second of "silence".
It is very unlikely that this would happen between cr/lf
and also greatly speeds up the process!
--
(To answer me, remove the ".net" from my e-mail address)
Arthur M. Hoornweg