Adding stringcollection to richtextbox text

[Claire]

Hi,
Is there an easy/nice way to assign the contents of a stringcollection to
richtextbox.lines rather than doing the following please?

foreach(string str in _EmailErrors)
{
rtb.Text += str;
rtb.Text += Environment.NewLine;
}

thanks
Claire

 

[Marc Gravell]

Not any nicer, but a lot more efficient:

StringBuilder sb = new StringBuilder();
foreach (string s in yourCollection) {
sb.AppendLine(s);
}
rtb.Text = sb.ToString()

You could refactor most of this into a helper function. to avoid
repeating the code.

Marc

 

[Peter Duniho]

Hi,
Is there an easy/nice way to assign the contents of a stringcollection to
richtextbox.lines rather than doing the following please?

Marc's example is more efficient than building up the Text property one
string at a time. However, you asked specifically about assigning to
the Lines property.

IMHO, at the very least it is likely to be more efficient, as compared
to the code you posted, to copy the strings to an array explicitly with
a foreach loop, and possibly even more efficient than the StringBuilder
code Marc posted. However, you might find the following simpler to
read as well:

string[] rgstr = new string[_EmailError.Count];

_EmailError.ICollection.CopyTo(rgstr, 0);
rtb.Lines = rgstr;

That does the same basic copying, but without having to write the loop
yourself.

Pete

 

[Claire]

Thanks to Marc but also thanks Peter. That's what I was looking for
I knew it was possible, just couldnt remember the required interface. I can
change my collection type easily enough

Claire

 

[Marc Gravell]

Complete aside, and an implementation detail only - but I looked up
the TextBoxBase.Lines[] setter in reflector... I cite this only
because it made me chuckle ;-p Of course, it also removes the need for
a string-array, but in the grand scheme that isn't really an issue...
On the other hand, it is often useful to know which of two approaches
is the simple get/set, and which is essentially a funtion. In this
case, .Text is the direct approach, and .Lines is the shim.

public string[] Lines
{
get {...} // the reverse...
set
{
if ((value != null) && (value.Length > 0))
{
StringBuilder builder = new StringBuilder(value[0]);
for (int i = 1; i < value.Length; i++)
{
builder.Append("\r\n");
builder.Append(value);
}
this.Text = builder.ToString();
}
else
{
this.Text = "";
}
}
}

 

[Claire]

Lol, you don't surprise me

 

[Marc Gravell]

it might surprise Pete, though:
<q>and possibly even more efficient than
the StringBuilder code Marc posted</q>

;-p

 

[Peter Duniho]

it might surprise Pete, though:
<q>and possibly even more efficient than
the StringBuilder code Marc posted</q>

;-p

It doesn't surprise me. That's why I used the word "possibly". I
accepted the possibility that the Lines property is simply a wrapper
and took that into account in my reply.

And even though it turns out that the current implementation is no
different, that does not rule out a possible change in the future. The
fact is that storing all of the text in the control as a single string
array creates performance trade-offs, and it's always possible that in
the future it will be changed to allow better performance for the
line-oriented access methods and properties of the control.

It's well and good that you can inspect the current implementation
based on reflection, but IMHO it's a bad idea to use that information
as a determining factor in implementing one's own code. There's a
reason the implementation is normally opaque: the client of the
implementation shouldn't be depending on the specific implementation.

Finally, I will note that the Lines implementation _is_ more efficient
than the code you posted, even if only slightly. So right back
atchya.

Pete